Conceptual design of industrial systems: an approach to support collaboration

Abstract

The design of any industrial system is a complex problem where many domains are involved. Each domain developed its own way of modeling based on a mono disciplinary perception. This leads to a communication problem and consequently to expectations on the formulated solution that do not correspond with the real solution. To enable the communication between domains and to preserve the match between intentions, expectations and reality of the system to be designed, a combination of a soft and hard systems approach is used to define a Conceptual model for Industrial Systems (CIS). The use of the model during design is illustrated for the technical domain, but has proven to be applicable for the organization and information domain as well.

1 Introduction

One of the recurring problems in any large-scale design project is the relation between the multidisciplinary design and the mainly mono-disciplinary participants. There is a clear mismatch between the intentions of the decision makers and the perceptions of the domain experts. This mismatch can only be explained by assuming a communication problem. Every domain developed its own vocabulary and its own specific way of conceptual modeling. Although often based on “a” system approach, the models differ significantly with respect to the defined elements and relations. For example, organization experts consider organizations as combined social, technical, and economical systems; Logistics emphasizes an integrated approach to deal with an operational system; Information technology developed several approaches for the design of information systems. They all construct conceptual models to formulate problems and find solutions. However, each of these conceptual models covers only part of the elements and/or relations of the system as a whole. Apparently, conceptual modeling is considered part of the domain itself.

During the last decades, there is a clear tendency to expand conceptual models in order to include more elements and aspects of the whole system to be designed. For example, until shortly object oriented information system methodologies were used just to design software systems; the more recent Object Oriented Change and Modeling Language (OOCL) is used to design and understand business systems as a whole (Swanstrom 1998).

However, expanding conceptual modeling from a domain specific view does not solve the problem of the different system perceptions as mentioned above. It rather invites to a fortified defense of the domain borders and complicates the communication between the domains. The result is a problematic cooperation, which complicates the job of project management in order to achieve the common project goals.

Our approach is to avoid the differences in system perceptions by considering the activity of conceptual modeling a generic interdisciplinary rather than a domain specific activity. The term “interdisciplinary” denotes cooperation with a common objective (and by this a common perception of the system). This objective is and stays the starting point for all activities during the design project and project management serves this objective. An interdisciplinary approach still incorporates domain specific concepts, but it starts from a single system concept. This single system concept supports an improved and unambiguous cooperation and communication between the different domains.

Therefore, the main questions that will be answered are:

• 1. What methodology can be used for generic conceptual modeling?

• 2. Until what stage of design can a generic conceptual model be used and how does it connect to domain specific conceptual models?

With respect to the first question, the “systems approach” emerged during the last half of the 20th century originally as an interdisciplinary approach to study “systems.” It opens the way to a generic conceptual way of modeling of industrial systems, thereby avoiding the jargon and specifics of separate domains. Here the systems approach will be elaborated by starting with a general concept for purposive systems. This concept will lead to a real conceptual model for industrial systems (CIS) until the level, where single domains inevitably have to become specific.

With respect to the second question, the use of the conceptual model during a design project will be explained emphasizing the interaction with domain specific concepts. In order to achieve a concrete and applicable result, the domains considered are restricted to Technology, Organization, and Information Technology. Other domains like Sociology and Economics could be added, but are not considered here.

2 Problem definition

To assure the validity and correctness of a conceptual model, most domains develop verification and validation activities. Figure 1 shows these activities [based on (van Gheluwe 2000)]. There are three “systems”: the real system with its (measured) input and output, the conceptual model of the system with assumed input and required output and finally the physical model with modeled input and output. The conceptual model usually exists in the mind of the modeler, based on perception and expressed in modeling elements and rules. The physical model is the result of using domain specific tools, varying from drawings to fully operational prototypes.

Fig. 1

Verification and validation activities

Validation checks the consistency of measurements in the real system with the physical model. There are various kinds of validation. Concept validation between reality and the conceptual model is primarily the evaluation of realism of the model with respect to the goals of the study. Structural validation concerns the evaluation of the structure of the physical model with respect to the perception of the system structure. Behavioral validation evaluates the behavior of the physical model. All kinds of validation depend on the presence of a real system and offer the possibilities to judge the quality of a model. Validation is answering the question: “Is this the correct model?”

Verification checks the consistency of a physical model with respect to the conceptual model. It is answering the question: “Is the physical model working correctly?” Verification is considered an activity that exclusively belongs to the domain itself.

Validation is in fact the interface between the domain and the other domains, in order to assure confidence in the modeling results. In Fig. 1 the boundaries of the domain are denoted by the dotted rectangle. The way in which the subject matter experts make their conceptual and physical models, is controlled by the validation activities. In practice this leads to two types of questionable situations:

• 1. Domain related support is considered a “blackbox”: just pop in the questions and correct answers will be returned. Validation has become the responsibility of the subject matter experts.

• 2. In the case of innovation projects the possibility for validation does not exist, because there is, as yet, no real system. The real system itself is a subjective perception of each participant involved.

Returning to Fig. 1, the absence of a real system prevents the use of validation activities. The only way to guarantee the correctness of modeling results now is fully dependent on verification. For this reason, it is necessary to involve other domains in the verification activities. The structure of the conceptual model must be implemented in a physical model in such a way that it can be recognized (and thus verified) by all parties involved. This is also important for the behavior of the modeled system.

“Collaborative” is therefore defined as combined verification of a common conceptual model. The concrete advantages of “collaborative” conceptual modeling will be:

• 1. An improved correspondence between design expectations and operational reality. The operational system itself will not be “better,” but the results of the system will better fit to the expected results. Indirectly this may lead to better systems, if the expectations are not satisfactory and urge the creation of a better design.

• 2. The construction of “shared memory” for succeeding (re)design projects by creating a “shared meaning” for system related terminology. The conceptual model represents decision-making in defining goals, restrictions and alternatives. Future projects can use this information to decide upon the level at which a design revision effects the original design.

The conceptual model will always be required for communication on and feedback of detailed designs. The use of the model supports the structured recording and evaluation of elaboration and changes. This satisfies the major condition to construct “shared memory,” from which future design processes can draw again. Shared memory starts with “shared meaning” and the model plays a major part in this (Konda et al. 1992).

3 A systems approach for a conceptual design model

The systems approach evolved as a generic domain independent approach during the last decades to investigate and describe “systems,” not only by studying the elements but by emphasizing the relations between the elements (Wiener 1948; Bertalanffy 1968; Beer 1985). The systems approach supports decision-making by formulating problems “in terms of systems.” A system is defined as a: “set of elements that can be distinguished from the entire reality, dependent on the objective of the researcher. These elements are mutually related and (eventually) related with other elements in the entire reality” (in ‘t Veld 2002).

In literature, systems approaches are classified in different ways (see a/o Jackson 1991; Whitmore 1998; Wigal 2001; Daellenbach 2002). The classifications range from dividing systems approaches according the researcher’s subjective or objective system perception (e.g. Keys 1991) to dividing systems approaches according the system’s complexity level (e.g. Boulding 1956; Checkland 1981). Applications of the systems approach are divided into three categories: “hard” systems approach, “soft” systems approach and “critical” systems approach (Flood and Jackson 1992).

Hard systems approaches consider a system logically based and capable of unbiased description. They are characterized by the modeling of purposive systems in order to optimize a performance or required objective. The basic assumption, whether or not implicitly, is that the problem is stated right and unambiguous. Typically hard systems approaches are Operations research, systems analysis, software development, database design and systems engineering.

The soft systems approaches consider a system a subjective perception: dependent on the observer the same system is presented in different ways. The observer himself may also be part of the system and may have his own objectives besides the system’s objective. Soft systems approaches therefore are mainly aimed at the understanding and the formulation of these so-called ill-defined problems and address the “what” question instead of the “how” question.

The critical systems approach emerged in the 1980s and “sits somewhat uncomfortably in the overlap between sociology, organization theory, systems thinking and by extension management science” (Daellenbach 2002). This approach looks at the methods developed by hard and soft systems approaches from the perspective of existing social structures and aims to define the conditions for their applicability. The contribution will result in a better definition of preconditions for problem statements and the period of validity of solutions.

The hard systems approach is in fact part of the soft systems approach. Once the stakeholders reach agreement on the problem statement (a consensus on subjective perceptions), methods of the hard systems approach can be used to solve the problem. Recapitulated briefly, the soft systems approach aims to state the right problem and the hard systems approach aims to solve the problem right.

The design process of an industrial system requires a soft systems approach to deal with different perceptions. The design process starts with a so-called ill-defined problem. The first steps of the process must lead to an agreement on the objectives and conditions. By then it is called a well-defined problem.

Example

Efficiency generally forms part of the objective of an industrial system as a whole. But an operations manager interprets efficiency as a need for a high and constant degree of capacity utilization (an operational objective), which can be achieved by high stock levels; However, a financial manager interprets efficiency as a need for low capital costs (a financial objective), which can be achieved by low stock levels in contrast with operations.

Using a hard systems approach only would pass over the proper objective definition and will lead to:

• 1. Accepting system boundaries as given. For example, looking at the effect of economic lot sizes, if one does not take the environment of the total supply chain into account, the savings may be smaller than the extra costs (Christopher 1998).

• 2. Considering elements as being naturally defined. If one regards an organization as a system, often the existing departments are regarded as the elements. But the departments are the result of design processes in the past. By doing so, the assumptions and starting points of these earlier design processes are implicitly imported into the new design process, with its new objectives and in a changed environment.

Research in a “systemic” way aims to identify the general, structural and functional principles that can be applied to one system as well as to another.

Example

The activities at a container terminal are performed by many types of equipment; there are quay cranes (QC), stacking cranes, straddle carriers (SC), multitrailer vehicles, automatic guided vehicles (AGV), etc. Yet, regardless of the equipment used, all activities are traced back to three types of functionality: to transfer, to transport and to store. These form the functional principles of all activities in any container handling system.

Activities expressed in terms of their functionality will be called “functions.” Now the problem is to find a system concept in a hard systems approach, which can be generally applied within the design process of an industrial system, taking the soft systems approach into account, which can provide a more or less lasting framework for specification and review of industrial systems.

Such a system concept will be called a conceptual system model and these models should contain functions as elements. Checkland (1981) positions the use of these models in his Soft Systems Methodology (SSM), the most widely used and accepted soft systems approach. The basic principle of SSM is shown in Fig. 2.

Fig. 2

The soft systems approach

Step 3 is the first step, which can be called “Systems Thinking.” The free form description of the system (“rich picture”) is analyzed and “root definitions” are defined by abstraction. Relevant systems are distinguished in which activities are formulated. A number of activities is declared absolutely necessary for the system and these are the root definitions. A correct root definition satisfies the so-called CATWOE principle. It states explicitly the Customers, the Actors of the activity, the Transformation performed by the activity, the World view (Weltanschauung) of the activity, the Owners and the accepted preconditions from the Environment. The root definitions are used to construct conceptual models in step 4. In the next step these models are compared with reality as described by the rich pictures. The comparison leads to the identification of feasible and realizable changes. These changes determine the actions required to improve or solve the problem situation.

One of the main shortcomings of SSM is that “the objective” is missing in the definition of a root definition according the CATWOE principle; the very same objective, which was found to be the expression of subjective “perception.” Therefore, in order to apply a hard systems approach in the conceptual models, the objectives must be preserved by defining the elements as “functions” rather than as “activities” or “tasks.”

There are only a few models that conform to the function approach in order to construct a conceptual model of an industrial system. The models are the Formal System Model (FSM) of Macauley (1996), the Viable System Model (VSM) of Stafford Beer (1985), the Steady State Model and Innovation Model of in ‘t Veld (2002) and the Control Paradigm model of de Leeuw (1982). FSM, VSM, and the Control Paradigm focus on the modeling of control, there is no conceptual representation of products or transformations being made; while the emphasis is on industrial or producing systems, the focus will be on the models of in ‘t Veld. However, some general rules can be derived from the other models that should hold for all conceptual models of industrial systems:

• 1. There should be some objective and a measure of performance.

• 2. There should be a decision-making process with decision-making resources.

• 3. The system should be stable or be able to recover.

• 4. The system is part of a wider system or an environment.

• 5. The goals of (and thus the functions within) control can be divided in objective-keeping and objective-adjustment goals. Beer calls the objective-keeping functions System 1, 2, and 3 (“here-and-now”) and the objective-adjustment functions System 4 and 5 (“there-and-then”). de Leeuw calls them “routine control” and “adaptive and strategic control.”

• 6. All models recognize the property of recursiveness. Each function in the model can be regarded as a complete system again.

in ‘t Veld (2002) defines two separate models: the Steady State Model and the Innovation Model. The Steady State Model exactly matches the objective-keeping functions of all models mentioned above and the Innovation Model all objective-adjustment functions. Above that, in ‘t Veld relates the functions to the primary operational function (the “transformation”) of an industrial system, stating that these systems always

• 1. have repetitive processes. They do not make one single product, but they aim to make many (more or less) identical products.

• 2. should not only control the making of a single product but also the making of a series of products.

• 3. have many repetitive processes and that it depends on the goal of the researcher, which process will be considered the primary process. Not only products are being made in a repetitive way, but also orders are being handled repetitively, and information is being processed repetitively. Selecting the repetitive process to consider, restricts the model of the system to one so-called “aspect.” For each aspect a complete Steady State Model can be constructed.

For this moment, the Steady State Model will be further explained. The Innovation Model will be explained in the description of the design process of an industrial system. The design process is the consequence of changed or new objectives.

The steady state model represents the required functionality for only one single aspect of the system. The design of a multidisciplinary product or system requires several steady state models, one for each aspect. Each aspect will be reflected by a single flow of elements.

Considering an industrial system, three aspects should always be included in the conceptual model. First of all the “product” as a flow of elements to be transformed. To make a product “resources” (people, tools and equipment) are required. To be able to use them, they must enter the system and they will leave the system as used resources. The third aspect is the flow of orders; without customer orders no products will flow and no resources are needed. Orders are transformed into handled orders. The combination of these aspects with the control paradigm of de Leeuw results in the basic CIS (Veeke 2003, see Fig. 3).

Fig. 3

Basic conceptual model for industrial systems (CIS-model)

In this model the processes are shown in a structure including a control function. The control function translates requirements into feasible standards for each of the aspects and their interfaces. Zooming in one level results in three one-aspect models that are steady state models on their own, but they are related by a task-progress interface between Perform and Operate and an assignment-relapse interface between Use and Operate. Each of the steady state models consists again of a control and process function and represents a complete function.

In order to stay clear and to preserve the notion of “objective” (preventing the same problem as with the CATWOE principle), now the terms “function,” “process,” “transformation” and “task” will be defined unambiguously. During this, the complete Steady State Model will be constructed and it will finally be positioned into the structure of Fig. 3.

Each form of industrial activity fulfills a function, transforming input into output, based on requirements from the environment or surrounding system. Figure 4a shows a function as a black box.

Fig. 4

a The function blackbox, b Function control

Neither resources nor organization nor technology are specified yet, only the physical realization (the output) and the performance are represented. A function is therefore defined as “the required contribution of an element to a wider system to which it belongs.” How this contribution is achieved is of no concern here, it should only agree with the requirements. Thinking and describing systems in this way preserves all possibilities to achieve the required output and opens the way to consider other technological and organizational possibilities than the one being used now. If there is no need for the output, the function is useless.

Example

A dynamo of a bicycle transfers mechanical energy into electricity by using the rotations of the wheel; this is a task description for the function “to produce electricity.” The function can be fulfilled in many other ways (for example, by a battery). A task description is device specific.

The output is physically realized by a “process” and according the control paradigm (as explained with Fig. 3) the performance should be achieved in a controlled way (see Fig. 4b). Function control is introduced as the part of control, which translates “requirements” into “standards” for the process. The output of the process is registered in “results,” which are translated again into terms of performance. For example, an outside requirement like delivering an order at a certain delivery time, is translated into an internal production planning scheme for the composing parts production and assembly; and at a container terminal, a customer requirement like a required berth time of 24 h for a ship to unload and load is translated into working packages/production rates per shift/QC.

These translations deliver standards for the process in order to know their (lower-level) objectives and to define things like “progress” during operation (the interface with the perform function of Fig. 3). Within function control two functions are required: the initiating function to deliver the standards and an evaluating function to deliver the performance. Both functions interact with each other, which may lead to a redefinition of the standards in case of regular deviations in the results.

The process function correctly and repetitively transforms correct input elements into correct output elements. Based on this general definition three function zones within the process blackbox can be distinguished (see Fig. 5):

• 1. An input zone, taking care of the correctness of input elements.

• 2. An output zone, taking care of the correctness of output elements.

• 3. A transformation zone, transforming the elements in a correct way.

What “correct” means is expressed by the standards; in the input and output zone it applies to the facets quality and quantity of elements. Quality functions will be called filter functions and their objective is to guarantee that input elements agree to the quality standards, otherwise they are not allowed to enter or leave the process.

Fig. 5

Processing functions within the process

Quantity functions are buffer functions for cases that the input flow rate temporarily exceeds the transformation rate or output elements cannot be delivered immediately. Furthermore the input zone may contain a function to uniquely identify each element (encoding) for use in the transformation, and the output zone may contain a function to identify it for use by the environment (decoding). The latter could be, for example, the way of packaging and user manuals.

All of these functions affect each single element and each single transformation, but there are also functions required to take care of disturbances within the process itself. Each function defined until now, has standards to be achieved, but it may happen that reality shows deviations from these standards. Due to a bad supplier the input flow may become too small for a while, and vice versa: Due to disturbances in the transformation the buffer function may overflow, etc.

Three types of control may be required to provide controllability:

• 1. A feed forward control loop, measuring the cause of disturbances.

• 2. A feed back control loop, measuring the result of disturbances.

• 3. A material repair loop for elements that were not correctly transformed but can be repaired.

Control loops consist of a measurement, comparing, deciding, and intervention function.

Example

Six hundred containers must be unloaded from a container ship; the standard time taken to unload the ship is 10 h (standard value 1). Each QC unloads 30 containers/h on average (standard value 2). So two QC are assigned to this operation. If after 6 h of operation the number of containers unloaded is less than expected, an extra QC is assigned. This is an example of feed forward based on a disturbance in throughput. From repeated monitoring of unloading ships, it appears that an extra QC had to be assigned regularly. Now two possible decisions can be made: decrease the standard value for the QC to 25 containers/h or increase the berth time of ships. The latter will probably not be accepted by the environment. This is an example of function control.

By this the complete steady state model for repetitive processes has been defined. The model is recursive in the sense that all functions within the model can be regarded as complete functions again. The steady state model is a real conceptual model for use in an industrial system. It has all the characteristics of a conceptual model for objective-keeping processes and is empty with respect to resources, tools and methods.

A function description must be determined by means of abstraction from the physical reality in order to construct a conceptual model. It is not important “how” something is done, but “what” and “why.” Abstraction to functions offers two advantages:

• 1. It stimulates to be creative and to radically change the way of realization, either by different technological tools and equipment or by combining functions in a different way. It is a structured pathway to reach innovation, next to the other path of “accidental creation.”

• 2. If the design is recorded in terms of functions, the basic assumptions and choices made during the design process remain clear and accessible for future design projects. This construction of “memory” prevents the “invention of the wheel” once again and excludes the implicit assumption of superseded conditions (see example).

Example

During the design process of the highly automated Delta Sea-land Terminal (as a part of ECT in Rotterdam) the organization of the container “stack” (storage) appeared to be one of the most important factors for the performance of the terminal as a whole. It was shown that reshuffling containers during their stay in storage would significantly improve the effectiveness of the final transfer process. However, based on experience with manual container handling the following principle was implicitly applied: “a container once stored will not be moved until the moment of final export.” The most important reason was the risk of container loss or damage. This risk was no longer under discussion with full automation and therefore this principle was no longer valid.

Figure 5 also shows the difference between the terms of function, process and transformation. A function expresses the objectives, a process the repetition of transformations. As soon as a transformation is expressed including the resources being used, it will be called a task from now on.

Each of the rectangles Perform, Operate, and Use of the CIS model of Fig. 3 can be represented by a steady state model as depicted in Fig. 5. Showing the three aspects “order,” “product,” and “resource” in one model, explicitly illustrates the requirement for a well-defined coordination between these three. The combined (function and process) control on these aspects should preserve the feasibility of the requirements and focus the attention to disturbances, which affect more than one of the flows. For example, maintenance programs and disturbance characteristics of resources directly influences the assignment possibilities for the Operation, and the level of detail of tasks sent to the operation directly influence the flexibility of process control there.

4 Using the conceptual model for industrial systems model in a design project

In the course of the design process, the level of detail of the CIS model increases continuously by succeeding cycles of problem formulation and solutions, or in terms of the previous paragraph by translating requirements into standards. Zooming into the elements of a CIS model results in new steady state models at a next aggregation layer. As such, the CIS model is a frame of reference for all domains involved. The model plays an important role in problem formulation: each solution or each decision formulates new problems, in more detail or tapered to one or more functions (subsystems) or aspects.

By this it becomes possible to fulfill the requirements of the design steps, even in a changing environment where “streamlining the existing” is not enough anymore but “starting from scratch” is necessary in order to make use of the new opportunities. The pressure to cut down costs, to reduce lead times, to grade up quality, and in general to enhance the effectiveness and productivity of industrial systems has increased enormously in the last decades. As a result, the importance of “(re)engineering” has grown more and more (Davenport 1993). Above that, research has shown that decisions made during the design period determine 70% of the product’s costs while decisions made during production only account for 20% of the product’s costs. Therefore, any cost reductions possible in designing the industrial system should be carefully investigated.

The number and possibilities of tools for design expanded simultaneously by the development of information technology. For example, Computer Aided Design (CAD) and computer simulation are common property now. Above that, information technology changed the contents and structure of industrial systems. The increased speed of communication influenced decision-making processes and the technological tools became more advanced by the use of automation. But starting from scratch incorporates the risk of errors being repeated or of re-inventing the wheel. To rule out this risk, design decisions and principles should be recorded in terms of the CIS model, since the model is conceptual and fundamental with respect to functions and processes. To determine the position of this model, the characteristics of the design process itself have to be described by means of a conceptual model.

Several conceptual models for a design process have been developed. From a classification by Konda et al. (1992), it is concluded that these models mostly are developed from the viewpoint of a single domain. There are models for the design of technical systems or products, for information systems, and for organizations. An industrial system, however, covers all these aspects.

In order to support an interdisciplinary approach of the design of an industrial system, a step preceding the different (parallel) design trajectories of each domain is required. The design is therefore considered a combination of the design of a product (the industrial system itself) and the design of a process (the way in which the industrial system will operate). The product design concerns the determination of the objectives of the system. Central questions in this process are “what is required?,” “what is feasible?,” “what functions are to be fulfilled by the system?” It is a strategic decision process and it will be denoted by “function design” from now on. Additionally, the way in which the system will operate, concerns the definition of structure (organization and communication), processes and resources, and it will be denoted by “process design.” Process design deals with the optimal utilization of resources, technology and information, and belongs therefore to the field of tactical decision-making.

Function design covers the performance part of the CIS model by defining requirements, standards and performance, while process design covers the process part. Function design makes the difference between innovation and improvement. Usually improvement only concerns the reorganization or reengineering of an existing system, which implies a rearrangement of functions or a different interpretation of functions. Innovation concerns the extension, reduction or change of functions as a consequence of the introduction of new technology, resources, and/or organization.

Jonas (1997) distinguishes three steps in the design process: analysis, projection, and synthesis (see Fig. 6). Jonas states: “Transforming a vague feeling of discontent into a solution turns out to be a three-step process of reducing uncertainty (contingency). The traditional concept of industrial design neglects the first two steps and acts at the very end of the process.” The function design as mentioned before, corresponds to the first two steps according to Jonas. After these steps, a “problem” is formulated that can be used for process design. During the first step (analysis) a feeling of failure or discontent (e.g., “the market asks something different”) is translated into a number of possible reasons (e.g., “we are too expensive,” “we do not make the right product,” “we do not deliver in time”).

Fig. 6

Design as a three-step process of “problem solving” (Jonas 1997)

In the step called “projection” the feasible and desired possibilities are investigated that may remove these reasons (“expand,” “shrink,” “innovate processes,” “innovate products,” and “automate”). Choosing between these possibilities, results in the definite problem formulation for the design trajectory.

Most literature on design concerns process design only. During function design, however, it is determined what can be required at all from the system and this is the starting point for the process design. Feasibility cannot be achieved without iterating with parts of the process design (albeit provisional), because the efforts to be expected are to a large deal due to the resources. Having determined the feasibility, realistic requirements can be formulated and a definite configuration can be selected, which will be elaborated in full detail during the process design.

Example

The Delta Sea-land Project (DSL) of ECT Rotterdam was a design trajectory to develop a largely automated container terminal. This project was preceded by several years of research to determine both the resources and the technology that were most appropriate and feasible to reach the intended results. In those years of research, for example, several alternatives were investigated for the quay transportation system, such as rail-bound transportation, conveyor systems and free ranging automated vehicles. In the end a system with automated vehicles was selected based on requirements of flexibility, productivity and technical feasibility. How to construct these vehicles (with respect to automation and technology) and how to control them—and even which part of the sea sided functionality they should fulfill—was not yet determined at that time. It was clear, however, that this system could offer the best theoretical effectiveness and theoretical productivity.

In ‘t Veld distinguishes four iterating functions for the objective-adapting process (Fig. 7). At the right hand side the CIS model is shown as the system resulting from this design process. The second step of the innovation model is called “define alternatives” to emphasize the iterative character of the process.

Fig. 7

The innovation model of in ‘t Veld (2002)

in ‘t Veld used “make policy” originally, but a policy (or selected alternative) is achieved after several iterations via confront and tune and (provisional) developing.

The figure shows that function design encloses the steps “explore environment and define objectives,” “define alternatives,” and finally “confront and tune”. The process design takes place in the step “develop and organize.”

4.1 Function design

Function design aims to determine a system configuration that is able to provide a required performance in an optimal way, i.e., to provide an intended result with acceptable efforts. For an industrial system, this can generally be expressed by “offer the required service with acceptable costs” (Lambert 1997). During function design, the system configuration should be tested for feasibility and desirability.

The steps of function design will be denoted by the functional terms of in ‘t Veld’s innovation model.

4.1.1 Step 1 Explore environment and determine objective

During function design the environment mainly consists of the customer market, the society, the company to which the system belongs, and the chain to which the system belongs. By exploring the environment, the need of the environment (the required service) is determined. This need is translated into objectives, preconditions and principles. Preconditions fall outside the range of influence of the system and are firm restrictions for the rest of the design trajectory. Examples are statutory regulations, environmental laws and the like. Principles are conditions drawn up by the company’s culture. They can be influenced but changing a principle goes beyond the scope of the system to be designed and often involves high costs.

Objectives are expressed in terms of the CIS model:

• 1. Regarding the order flow: What is the demand composed of, what is the required lead-time and what is the required reliability of delivery?

• 2. Regarding the product flow: What are the products required, what is the required quantity and quality, what are the costs and flow times?

• 3. Regarding the resource flow: What is the required quality and quantity of resources with respect to the order and product flows?

For the relation between the flows this leads to questions as:

• 1. Between order and product flows: What is the ratio between order quantity and product quantity?

• 2. Between resource and product flows: What is the required flexibility of utilization?

The objectives for the order and product flows strongly influence the resource flow. In cases of (a/o) large seasonal influences (e.g., sugar industry), continuous operation (e.g., service departments), and dangerous work (e.g., chemical industry) social factors play a major role. In addition, the increasing degree of automation did enable new modes of operation and working methods, but was not always welcome and has led to considerable commotion with innovations.

At the end of this step the objectives are expressed in terms of intended results.

Example

For the DSL-terminal a project program resulted which defined the expected arrival pattern of deepsea ships, feeders, trains and trucks, and the total number of container moves per year. A source-destination rate (modal split) of the containers was contractually established and it was assumed that containers on average would stay 3 days on the terminal (dwell time). The terminal should be able to handle 500,000 quay moves/year and with each QC 600 containers/day. The systems (excluding the QC) should have an operational reliability of 99%. All these requirements should result in acceptable port times for ships, service times for trains and trucks and a number of net operational hours. These were all specified in the project program. In the CIS model the product flow represents the individual containers, the order flow is represented by ships, trains, and trucks (they are directly customer related). The resource flow contains QC, AGV, automatic stacking cranes (ASC), SC, and the area.

4.1.2 Step 2. Define alternatives

During this step, a number of alternative configurations is being determined that may satisfy the requirements. The definition of alternative configurations is an alternation of thinking creatively and structuring. Creativity does result in new ideas, but the result of it can and should be reflected in terms of the following structured approach.

The definition of alternatives is an iterative process itself, which can globally be defined as a repetition of cycles consisting of context establishment, function establishment, structure establishment and behavior establishment (Ackoff 1971). Each succeeding cycle takes place on a next aggregation stratum. The contents of each part of a cycle are explained below.

• 1. Context establishment

In terms of the systems approach, this is the determination of the system boundary. The system is considered a part of a larger chain. Upstream, the system can be expanded into the direction of suppliers, downstream into the direction of customers. Shrinking the system is also possible.

System concepts will result, in which different configurations can be selected. Each alternative has a primary function, based on the objectives.

• 2. Function establishment

The primary function is divided into subfunctions (zooming). For each subfunction the intended result is defined.

• 3. Structure establishment

Subfunctions can be particularized into both horizontal and vertical direction.

Horizontally there are two major ways:

• (a) Specialization/parallellization: the flows are being split or combined,

• (b) Differentiation/integration: the functions are being split or combined.

This step is of vital importance, because splitting and combining flows and functions influence both the results and the efforts that can be expected.

Splitting functions or flows generally results in increased costs (extra transfer actions, increased space requirements and the like). Combining flows may also lead to increased costs (complex technology, turnaround costs, extra sorting, etc.).

Particularizing into vertical direction concerns the control structure. Control echelons are introduced and the degree of autonomy for each function group is determined. This type of structuring indicates the controllability and control burden (the need for control)

As a result a number of structure concepts are defined. For each structure the results that can be expected are to be determined.

• 4. Behavior establishment

Each structure causes a “behavior”.

This shows itself on the one hand in communication and consultation requirements, on the other hand in time dependent phenomena with respect to the contents of a structure (stocks, throughput times, etc.). This step therefore determines the expected behavior: a behavior concept. Each structure shows its own specific behavior.

It shows that a feeling of discontent is translated into configurations consisting of a system and structure concept with a corresponding behavior concept. They lead to a problem formulation for process design. In terms of Jonas’s model the analysis yields system concepts and the projection phase yields structure and behavior concepts. The CIS model is the basis for the definition of system and structure concepts.

During the step of defining alternatives each of the domains involved should evaluate the feasibility of a configuration from its own perspective. The model is not bound to a specific domain and reflects clearly the environment, functions and structures. It is considered a “cognitive map” of the design. According to Dwyer (1998) such a map is “a system model from the perspective of how people involved with it will understand it.”

The determination of results to be expected is a part of process design already, albeit provisional. By means of draughts, prototyping, based on experience and by means of simulation each domain contributes to this determination. This illustrates the iterative character of designing.

If a system or structure concept is considered infeasible (the results to be expected do not match up to the intended results), this concept will not be elaborated further. For the remaining configurations the results in view and the results to be expected are specified now to the level of subfunctions. The CIS model does not reflect the behavior concept. It is a static model of the system. Step 3 will address this further.

Example

Returning to the DSL-terminal and zooming into the product flow, the different functions become clear (Fig. 8). The number of moves per year from Fig. 9 is specified here as a required number of moves per gross operational hour per QC. In order to have an idea of “progress” it is again translated into number of moves per shift and stack occupation figures. The type of equipment for each function to be performed has already been selected, but still a number of alternatives are possible. The AGVs can be equipped with a lifting mechanism or solely work as a transportation system (a technological alternative). The containers can be stacked parallel or perpendicular to the quay and the stack can be divided into a seaside and a landside (as logistic alternative). Operational control can be divided in several ways: seaside, landside and stack or only seaside and landside, or as a system as a whole, which is mainly an organizational alternative. Control for the AGV-system can be organized centrally or locally, a logistic alternative, etc. All the alternatives have consequences for the information systems to be used. They influence the way tasks are being scheduled and resources are assigned. In the next step they will be elaborated further for feasibility and expected efforts.

Fig. 8

The product flow of the CIS-model

Fig. 9

The CIS model at terminal level

4.1.3 Step 3. Confront and tune

Having the intended results and results to be expected, this step aims to determine for each configuration the efforts to be expected. For this purpose, the process component of the model is examined now. A process takes time and capacity (costs). Confrontation means for each domain involved the separate assessment of “can we do this?” and “do we want this?” Subsequently, all domains together try to tune to one another with any adjustments. For illustration purposes, common questions for each of the domains, which are to be answered for each alternative, are formulated below.

• 1. Technology:

Are the grouped functions technologically feasible? What kind of hardware (as well as developing time and capacity) are required? What are the consequences with respect to operations, maintenance and environment?

• 2. Organization:

What will be the departments? Are we able to and do we want to realize these within the existing organization? What are the demands on competencies of people and other means? Can they be obtained here or elsewhere? What education efforts are required?

• 3. Information:

What are the demands on architecture, software and hardware? What administrative systems, control systems and production support systems are required? Are we able to develop the systems required in house or should we hire capacity for this?

The results of “confront and tune” include a specification of results and efforts to be expected for each alternative. The alternative with the maximum theoretical productivity is selected first. The other alternatives are kept for the event that during process design this alternative still does not match the expectations.

Example

One of the alternatives formulated in step 2 concerned the stacking of containers: parallel or perpendicular to the quay. The main criteria for choosing between the alternatives are: distances for ASCs, AGVs, and SCs, but the most important fact was that automated and manual operations should be kept separate for safety reasons. Figure 10 depicts both alternatives for parallel stacking, where manual and automatic operations are strictly separated. Both alternatives have a big disadvantage: The distances to be driven would have been enormous for one of the transportation systems AGV and SC. This would have required an increase in efforts (by an increase in the number of vehicles used) and so both alternatives were rejected.

Fig. 10

Alternatives for parallel stacking

4.2 Process design

Process design starts at the point where a configuration is selected. The selection may be provisional as an iteration with the “confront and tune” function, where different configurations are being compared. The system has to be developed and organized now. By function design the structure of functions to be fulfilled, is reflected including intended results and (a first estimate of) results and efforts to be expected. These values are the target figures for the optimal process design.

Jonas (1997) notices that this is the territory of the traditional design approach. Process design is rather a multidisciplinary/monodisciplinary than an interdisciplinary trajectory. The methodologies of all domains currently contain a stage called “conceptual design,” probably based on the multidisciplinary requirements of the environment to which the methodology is applied. The conceptual design shows a large overlap with the function design of the preceding paragraph. The functions defined, however, usually cover only one single aspect or subsystem of the CIS model and use a terminology that originates from the domain itself. Representing this by the innovation model structure of Fig. 7 the multidisciplinary approach results in Fig. 11.

Fig. 11

A multidisciplinary design approach

The interdisciplinary approach used so far here takes all aspects and a consciously chosen system boundary into account during the function design. The result is shown in Fig. 12.

Fig. 12

The interdisciplinary design approach

For the domain “technology” the characteristic design steps will be described shortly and the connections between function design and process design will be illustrated now.

4.3 The design of technical systems

The technological process design mainly focuses on the resource flow of the CIS model. It concerns the design of machines, tools and transportation equipment. During function design the function grouping was established and they should be physically filled in here. Doepker (2001) distinguishes the following steps:

• 1. Establishing needs and generating ideas resulting in requirement specifications (the functional and design requirements and design criteria). Functional and design requirements have already been formulated with the conceptual model. The design criteria are described by Pugh (1990) and they consist of a product design specification (PDS), the organization and the personnel. The CIS model is an appropriate way to reflect these criteria.

• 2. Conceptual design is the decision making to obtain a concept. Doepker calls it a very important step, because design changes are still “cheap” to implement. He already refers here to the changes of one single design only.

• 3. Preliminary or detailed design. Pahl and Beitz (1996) call it “embodiment design;” layout and form are being quantified during this step. Materials and geometry are defined.

• 4. Final design. Detailed analyses (stress analysis, shaft design, heat transfer, etc.) are performed in this step.

• 5. Implementation.

During the steps 1 and 2, specific requirements are added by the technological domain, for example, concerning materials, safety, size, weight, ergonomics, etc. The steps 3 and 4 detail the design, eventually resulting in extra restrictions. These restrictions are given feedback to the other domains with reference to the commonly defined functionality in the CIS model. The more detailed insight with respect to “behavior” is added to the model.

The next example illustrates the combination of product flow and resource flow from the CIS model in order to achieve a complete functional specification of requirements for the technical resources. They form the basis for confrontation and tuning and the starting point of technical design.

Example

The import process of containers at a deepsea terminal covers the transfer process between ship and stack area. For the resources to be used it is decided to use QCs to unload, automated vehicles for the transport function and stacking cranes to stack the containers. Transfer functions are required to transfer containers between the resources. Suppose this product flow for this part of the Operate function is modeled as in Fig. 10. One of the alternatives to be investigated during the confront and tune step of function design is the one where the automated vehicles do not have a lifting installation; the transfer functions are to be performed by the other equipment. By adding the resource flow to the product flow, Fig. 13 results. Now the technologists are asked to provisionally work out the vehicle design. The required functions are defined by isolating the vehicle part from Fig. 13 and zoom in on the assignment part. For illustration purposes all control functions are omitted. From the technological viewpoint, the size, speed, etc. of the vehicles are major design criteria. Vehicles always have a physical position, use space and they should be “stored” in all cases where waiting for a job or a transfer by QC and stacking crane is encountered. This becomes clear by zooming in to the buffer of assigned vehicles (Fig. 13). The Receive, Wait for SC, and Deliver functions are parts of the transfer functions of Fig. 14. The results and efforts to be expected with this type of vehicles in this configuration are to be estimated from these functions. Expected results will be the number of transports per time unit, while efforts will be the number of vehicles, their occupation and space requirements. The Wait functions can be given feedback to the overall design to take into account for comparison with other alternatives. The pure technological functions “Drive” and “Transport” will be worked out after the alternative is selected. In this case the results and efforts to be expected are accepted and have become standards for the technological design (Fig. 15).

Fig. 13

Product and resource flows in the container import process

Fig. 14

Functions in the container import process

Fig. 15

Vehicle functions in the container import process (QC quay crane, SC stacking crane)

5 Conclusions and future research

In this paper the conceptual interdisciplinary CIS model has been defined that can be used by all domains involved in the design of an industrial system. The model is a common frame of reference to support communication and decision-making by different monodisciplinary approaches. The model is also used to record conditions, decisions and assumptions that lead to the final design. The model is primarily used to better fit the expectations on the performance of a design with the performance in reality. Using the model will not automatically lead to better designs, although a correct expectation may lead to reconsider decisions in an early stage of the design project.

The model has first been used at the start of the large design project FAMAS.MV2 to study the future land extension for container handling in the Rotterdam port area (Veeke and Ottjes 2002). At this moment it is being used as a starting point for a research and realization project to enlarge the use of Radio Frequency Identification (RFID) in the control of industrial processes.

Meanwhile the model has been extended with a so-called process description vocabulary to extend communication on the conceptual model to the time-dependent behavior of the system In this way a connection is established to the field of simulation and is the validation of simulation modeling supported for situations where no real system exists yet. A correct connection requires a pure process interaction approach by the simulation platform.