Rapid Production Changes through the Coordination of Factory Layout Models and Activities

Changing the design of a factory in practice involves the change of a number of parallel and interdependent systems such as the machining resources and robot cells, the supply systems for electricity, water, air, heat and cooling, pneumatics and hydraulics, the systems for chip and waste handling, process fluid, communication networks, sprinkler systems, as well as the building construction. Thus the coordination of information and models, as well as of the design work activities, is of utmost importance to achieve a fast and flexible development process. This paper presents the results from a research project focusing on computer aided work processes and the communication of models between various stake holders in layout design. The primary objective was to provide methods for a coordinated factory development process with a facilitated information exchange and reuse of knowledge and models. Results concerning required layout and PLM (Product Lifecycle Management) functionalities, as well as modelling and communication principles, tested in an industrial case, are presented


INTRODUCTION WITH BACKGROUND AND PROBLEM DESCRIPTION
Factory layout design is a multidisciplinary, knowledge-intensive task that is vital for the survival of manufacturers in today's globally competitive environment. The need to design and construct a new factory or reconfigure the current one has increased largely because of the fast changes in customer demands both from a product quantity and a product variety aspect. Further, the factory design process affects not only the effectiveness of the project phase but also the subsequent production efficiency, in terms of the material flows, space utilization, energy consumption, working environment, and safety.
When designing a factory, the consolidation and integration of different models is of particular interest since the design of a factory involves many different stakeholders. These stakeholders, who come from the building, media, manufacturing and machine design domains, typically utilize different models and CAx systems from different system vendors.
The problem is that information is inconsistent: it resides in various systems and applications, in different formats and with various levels of detail and viewpoints. This is especially troublesome when companies who collaborate use software from different vendors using different data structures. To facilitate the communication and sharing of information between these applications, it is necessary to use common formats. There are many existing system neutral standards, but they are developed for different and more or less specific purposes, and are not harmonized with other aspects of the manufacturing domain.
For implementing an integrated information environment, OMG has worked on developing 'PDM Enablers'. PDM Enablers provide standard interfaces to PDM systems (Object Management Group 2000) [1]. Another study has focused on data exchange between heterogeneous PDM systems using PLM Services (Gunpinar and Han 2008) [2]. Yeh and Yoy (2002) proposed an) integrated data model, which is referred as a STEP schema, and JPDM (Joint Product Data Management), besides an approach for implementing a PDM system that uses STEP as a standard for the exchange of product data [3]. For implementing Collaborative Product Commerce in a virtual enterprise, Kim et al. (2006) defined product metadata through STEP PDM and then applied it to the integration of applications [4]. These approaches focus on the product, rather than on the manufacturing system domain.
For the integration of engineering applications the manufacturing domain through standard schemas, Lau et al. proposed a scheme based on STEP AP203 for integrated product design and process planning. With the proposed scheme and the STEP AP203 standard, they use the integrated schema for generating the product feature code. This approach does not include layout development [5].
Then there are approaches to implement an integrated and concurrent engineering environment focussing on specific areas, such as the exchange of design information, logistical analysis, and ergonomic analysis. Makris et al. (2008) and Chryssolouris et al. (2004) for example, suggested an approach for modelling data exchange in an Internet-enabled supply chain environment [6]. Data is modelled in a standard way as suggested by the ISO 10303 specification, and then converted into an XML representation that enables Internet-based data exchange in an easy manner. In another study, Kim et al. (2008) proposed a procedure for integrated ergonomic analysis using PPR +H , which is a schema that includes product, process, resource, and human information. PPR +H supports data exchange across heterogeneous systems [7]. With these standard schemas, engineers are able to easily execute ergonomic analysis without data collection. Lee et al. (2000) proposed a conceptual framework that is necessary for automatically generating a simulation model from graph-based process plans, which are used to capture operations for parts, their related resource requirements, and their temporal precedence relationships and resource configurations [8]. In another study, Kim et al. (2009) introduced a generic simulation-modelling framework to reduce the build-time for simulation models. It consists of a new layout modelling software called AutoLay and a data-driven generic simulation model called AutoLogic [9]. Gamberi et al . (2009) introduced integrated layout-flow analysis, which focuses on determining the space requirement for manufacturing-department buffers, transportation system requirements, performance indices and the time and cost of material flows spent in the layout and in MH (material handling) traffic jams [10]. Apart from this, there is a need for a more generic engineering environment.
The Virtual factory framework (VFF) [11] project has a more generic scope to enable the efficient management of products, processes, resources and factory information throughout the life cycle. VFF suggests a solution to integrating layout and flow simulation software and is based on the IFC standard. The IFC standard was developed for the building industry to support a standardized BIM (Building information model) [12] and is strong in representing connection points. However; the standard does not represent the geometry explicitly, which makes reasoning concerning placement and distances difficult. Further it does not relate to information concerning the production process, such as the sequence of operations -fundamental in the design of factory layouts, thus these types of concepts need to be added.
On the contrary, the STEP standard (ISO 10303 Product data representation and exchange) covers a wide range of information required within the automotive industry (Al-Timimi and McKrell, 1996). Apart from geometry; technical data and interrelations between products and processes and resources can be represented using the STEP application protocols AP214 or AP242 [13] [14], and the standard has previously been applied for modelling manufacturing systems and machine tools  [15]. But STEP is very generic and does not represent layout information explicitly on a semantic level although the technical data structures are able to represent this information.
Apart from information integration issues there is also the issue of information management on a higher level. All information is not necessarily integrated; on the contrary, sometimes it is more efficient, practical and even necessary to divide rather than to integrate models from different perspectives, purposes and detailing level. Further there is a need to be able to manage versions, permissions, support processes, etc.
In this work, the information integration issues are related to the industrial manufacturing development work flow for the purpose of specifying an IT environment which reflects the needs of industry. A specific industrial problem is that various existing commercially available CAD and simulation software are used, with the aim to continue using these systems while coordinating and integrating their results. Thus, the general aim of the approach is to utilize existing standards for representing complex data structures as long as possible, while adapting these structures to the domain of layout by combining the general standard information model with domain specific concepts.
Required functionalities and models in the industrial layout applications were identified, as well as issues concerning the interaction between various stakeholders. The issue of managing information from different sources was split into two: 1) How is core, deeply integrated, information represented and communicated in a system neutral way? and 2) How is information managed, even when it is not integrated into one information model, but split into traditional files and databases? It was investigated if STEP AP214 could be used for representing layout information in a standardized way. The approach was to treat a factory as any other type of product, following the principle of separating the semantics of an object (layout, building, machine tool) while using the same generic information structure common for all kinds of objects (Kjellberg) [16]. A layout was viewed as a type of product and product generic data was combined with the semantics of layout as described by Chen [17]. This approach was deemed feasible and together with an information framework based on commercially available PLM and CAD software, it forms the basis for a new information framework for factory design.

FUNCTIONALITIES AND MODELS IN FACTORY LAYOUT
The layout development process is typically divided into a conceptual phase and a detailed phase. Chen [18] defines a model of the whole factory design process which is here simplified with a focus on the layout development workflow (Fig. 1):

Fig.1. Different phases of the layout development
In general, the goal of the layout process is to place the equipment in such a way that it enables an efficient material flow for the intended product families and volumes. It has to be secured that media is dimensioned for all equipment and that the equipment fit in the building, meet constraints on space, foundation and surrounding areas and follow laws and safety regulations. Further, the layout should be easy to work with, fulfilling regulations concerning ergonomics and also operators' needs (Shariatzadeh 2012) [19]. Proactive companies also consider the flexibility of the layout, preparing for changes in volume or products variants.

Layout functionalities
In summary, the basic layout functionalities are:  Create a block layout to show the production flow and to place different areas such as operator working area, heavy machining area or transport corridors, according to constraints. Parametric design is a technique that can be used for developing a layout, using rules that calculate and create the geometry of an area (cell, line, section etc.) from specifications. The required area could for example be calculated based on the size and number of machines, adding a 20% of increase to provide space for corridors and expansion.  Dimension the media according to the total needs of the machines.
Create or retrieve a building model. A new technology for creating accurate building models is through the use of scanning of existing facilitiesas a reference for validating and correcting a CAD-model. Direct import of point clouds to the CAD-system is possible but not yet practical due to large size of point clouds. This decrease the performance of CAD systems.  Create or retrieve models of production resources such as machine tools, robots and equipment. Such models can be delivered by the suppliers.
 Simplify CAD-models. Since the supplier models often are created from a design perspective, they need to be adapted to the layout perspective; in particular the size in bytes needs to be decreased by simplifying the large CADmodels.  Calculate engineering properties. Normally, the center of gravity is not modelled in a machine model although it is essential information of a machine for installation and lifting purposes. Thus such a property could be calculated based on the geometry model and material/density of the various subsystems.  Modify models. When trying to fit models received by the suppliers into the layout, the engineer might want to reconfigure the placement of cabinets or modify the size of the model for the purpose of specifying the size and configuration of a new machine. One way of supporting this modification is to enable suppression of specified features/components.  Manage interdependencies: The media requirements can for example be automatically updated depending on the media attributes of a selected machine. Place models: Place models based on the intended flow of material, physical adjacency and other criteria. Specifically, a function which is important and often automated is the checking of physical collisions between geometry models. Configuration of resources is sometimes automated based on criteria such as minimum cost or adjacency constraints. The transportation cost and energy consumption of transport between machines can for example be calculated based on the flow in loads, the distances between machines and the cost and energy required for each distance. Spatial relationships can also be used to check the fulfilment of conditions concerning clearances, distances and tolerances among facilities. The safety distance between a truck corridor and the workspace of an operator could for example be checked with a message. Another example is suggesting a change of the foundation material based on a calculation of the mass and placement of the machine.  Design and verify the physical connections between the different components.  Plan and coordinate the construction of the building and installation of equipment.

Layout models
Layout models are designed by different disciplines. The types of layout models used can vary dependent on industry, but often include: Block layout, Building layout, Machinery layout, Foundation layout, and Media layout (Ventilation, Heating, Plumbing and electricity).
Production resources including machinery, transportation, robots, are core parts of the factory layout. Geometry models of resources should support the layout activities as described above, and ideally include: dimensions, outer shape, position and orientation of ports for media; fundament with placement of machine feet; position and shape of operator panels and service platforms; placement and envelopes of doors and other openings; center of gravity; material loading point. Further, the model should be structured in such a way that equipment can be reconfigured or deleted from the model. A concept model of the resource information required for layout is described by Chen [20]. Apart from the geometrical model, information is needed concerning required media and functional media interfaces:  For electricity; Power consumption and Main fuse  For ventilation; state air volume and pressure drop (air flow and minimum air pressure).  For compressed air; state pressure, consumption and purity requirements.  For heating systems; state pressure differential, flow and temperature.  For water; state pressure, consumption and pumping curve.  For cooling; minimum coolant pressure, state pressure differential, flow and temperature. External coolant connector  For exhaust; Exhaust flow, Dust particles, Oil mist If all information was accessible through one model, it would facilitate calculations such as dimensioning the media for all machine tools, or placing a machine tool on its feet, connecting it to media or checking that laws and regulations concerning required distances are fulfilled. Some layout programs do have such capability, but they are represented in the vendor specific format and cannot be communicated between CAx systems with all information in an interoperable way.

MANGEMENT, COMMUNICATION AND INTEGRATION OF LAYOUT MODELS
The multi-disciplinary nature of layout development results in the creation of heterogeneous, yet interdependent information from various actors and the task of coordinating this information is of utmost importance. The ultimate goal is that the right data is accessible at the right time to the right person which assumes that data is organized in a coherent information model, partly based on some standard formats. Even with this vision realized, there is a need to be able to manage versions, permissions, support processes, etc.
All information is not necessarily integrated; on the contrary, sometimes it is more efficient, practical and even necessary to divide rather than to integrate models from different perspectives, purposes and detailing level. In the project, the issue of managing information from different sources was split into two: 1) How is core, deeply integrated, information represented and communicated in a system neutral way? and 2) How is information managed, even when it is not integrated into one information model, but split into traditional files and databases?

Integration of information
The vision is that models including all relevant information should be possible to communicate between systems and combine into one layout. With "all" information we refer to what is sometimes called "intelligent models", that is, models which describe not only geometry but also the connection points and technical specifications related to layout, described in the previous chapter. If such information was represented in the model, it would facilitate reasoning, design and verification. Some layout programs do have such intelligent models (see Fig. 2), but they are represented in the vendor specific format and cannot be communicated with all information in an interoperable way. Fig.2. Defined machine feet, insertion point and connector type as well as technical machine data on a machine model When many interdependent components (and their models) emanate from different suppliers, the models need to be described in a way which is common to the different systems -a system neutral standard. There are various standards trying to solve this problem, where layout information can be represented in a system neutral format and specifically the IFC-standard and STEP AP214 and AP225 [21] standards have been studied.
The IFC standard [22] was developed for the building industry to support a standardized BIM (Building information model) and is strong in representing connection points. The geometry is structured to represent ports (connection points) explicitly. Ports can be given their own geometry and attributes, and the connections between ports are represented explicitly. Fig. 3 demonstrates different stakeholders involved in BIM. However; the standard does not represent the geometry explicitly. It does not represent the dimensions and tolerances or the semantics of the geometry, which makes reasoning concerning placement and distances difficult, e.g. placing the machine tool on its feet on a foundation and checking that the foundation is strong enough. Further it does not relate to information concerning the production process, such as the sequence of operations, which is fundamental in the design of factory layouts.

Fig.3. Stakeholders in Building Information Modelling
On the contrary, the STEP standard (ISO 10303 Product data representation and exchange) covers information required within the automotive industry.
A standardized representation of 3D geometries is complex; still almost all CAD software supports the import/export of geometry according to STEP. But also other types of data, such as technical data and interrelations between products and processes and resources can be represented using the STEP standard AP214 or AP242. Fig. 4 Technical data demonstrates the data model outline to represent relationships among a process, its used resource and the product to be machined according to STEP AP214.  Since the representation of operations as well as of technical data is within the scope of STEP it was investigated if STEP AP214 could be used for representing also layout information in a standardized way. The approach was to treat a factory as any other type of product, following the principle of separating the semantics of an object (layout, building, machine tool) while using the same generic information structure common for all kinds of objects (Kjellberg). Identification of basic information units independent of product type is one of the main principles enabling this approach that support modelling of a variety of machine tools and other manufacturing resources (Hedlind 2013) [24].
So the idea in the factory layout project was to view a layout as a type of product and test whether STEP could be used by combining the product generic data with the semantics of layout. Analogous with the tests in research addressing process planning, where the interfacing surfaces of tool and machine were annotated for a direct placement of a tool in the machine [25]; the feet surface was annotated as an interfacing surface to the floor. A test was made, implementing an interface to the Autodesk product "Factory design suites" for importing such enhanced STEP-models. This test was promising and the results will contribute to development in future projects.
The work flow to create machine model for the purpose of layout development is defined in Fig. 6. 1. Import (or create) machine model geometry 2. Simplify geometry if needed 3. Add layout related information to machine geometry a. Semantics such as feet and insertion point b. Components such as connectors c. Media specifications (from machine data card) 4. Save model (preferably in a library with easy access and PLM-functionality) Fig.6. Work flow to create a machine model for the layout development Fig. 7 illustrates an example of a machine model creation for layout development base on the aforementioned workflow according to STEP standard in a commercial software tool (FDS -Factory Design Suite 2012). The machine data card is represented using STEP AP242 (see Fig 7).
Commercial software tools cannot import/export this type of information (machine data card) in STEP (STEP geometry can be imported). Still they can import/export data if it is represented according to their own, vendor specific, XML schema. Therefore, to test the concept of importing "intelligent" models, a work around was implemented: the machine data card was converted to STEP part 21(clear text encoding) from excel, and then converted to the FDS specific XML format. The XML file was then imported to FDS and added to the machine geometry. Fig.7. Integration of machine geometry with technical data according to the STEP standard STEP to XML Integration in with Geometry

Management of information
The ultimate vision is to integrate and communicate data such that all relevant data is accessible at any time to anyone requesting it. This goal assumes that data is organized in a coherent information model, based on some standard format such as STEP. Until such information models are implemented, companies need to manage the information using traditional approaches like files and databases. Even when the vision is here for us to use, we still need to be able to manage versions, permissions, support processes, etc. Currently we are then faced with two main questions: 1. Which data do we need to manage? The answer here is essentially given by the information model for our domain of interest. 2. How do we split the responsibilities between the various applications that we are using? We still want to be reasonably close to the vision (right data available to the right person at the right time), while avoiding redundant data and potential inconsistencies. The answer to this question is given, again largely, by the application architecture. A third question is what processes to support; here we must rely on project and process models, as well as descriptions of lower level routines.
As discussed above, we need to manage and coordinate information which possibly is implemented in different formats and in sets of files and databases. Our approach was 1) to identify a unified, high level information model, 2) specify the information management functions, and 3) map the entities of the data model to the application architecture. In the project we showed this approach in a simple demonstrator.
The information model has been discussed above, but we include the one used in our prototype illustrated in Fig. 8. Note that the model is simplified and that we have omitted the Document item, which is used to carry file data items. The Document can be related to all items in the model. To support the information management tasks, we need a variety of functions, where we only discuss the high level ones here:  Support for a user-defined data model, i.e., we must be able to represent all item types in our information model, including their attributes and behaviour.  Support for lifecycle states, which must be possible to specify based on item type. A Production Equipment may, e.g., have states like Planned, In Use, In Service, etc., while a Document has states like In Work, Approved, Released, Obsolete, etc.  Support for versions of items, with different behaviour dependent on the lifecycle state of an item. Updating an item In Work may not affect the version, while the same operation on a released item creates a new version.  A relationship model supporting typical configuration management tasks, e.g. to update relationships correctly when new versions of dependent items are created.  Functions to search for and retrieve any items, based on a combination of attribute values, supporting wild cards, etc. It must also be possible to navigate the data along the relationships.  Provide process support, e.g., through a workflow engine, forcing a predefined set of activities to be performed in a specific order, by users having specific roles. Workflows are typically used for relatively small, well-defined, repetitive tasks, like document approvals or supplier interaction.  Permissions and access control, in a multi-user environment, based on item types, lifecycle states, etc.  A final, but important requirement is to have published and complete APIs, to allow different types of application integrations. The functionality we outline above, is what we can find in many commercial PLM products, but other platforms are conceivable, e.g., some ERP and document management systems. The system architecture we propose is illustrated in Fig. 9:   Fig.9. System architecture At the top we have the applications primarily used to create and update data; they could collectively be called 'authoring applications' (AA). They are used them to write documents, edit CAD models, and so on. These applications are generally running on the user's local PC where they also are installed. More often than not, they are file based, i.e., the context for an edit operation is one, or sometimes several, file system files. Next we have an intermediate layer, Application File Managers (AFM), managing the files from the AAs. Depending on the AA an AFM may or may not be needed. Typically 3D CAD systems require AFMs to manage the often complex relationships between the application files, while office programs, like MS Word and Excel, do not.
The PLM layer manages the complete factory model, including files and items and their attributes and relationships. The PLM system also supports projects and processes. This system is always a client server application, i.e., most of the application logic is executed on the server, where also the persistent data is stored: a database for item data, and a vault (generally a protected file area) for the files.
The Asset Management layer is a catch-all for transaction oriented database applications, typically used to manage the operative data. Here this includes work orders for maintenance tasks, spare parts for production equipment, and much more.
In the demonstrator we have used Aras Innovator for the PLM layer, Autodesk Vault for the AFM layer, and AutoCAD Factory Design Suite for the AA layer. Aras Innovator is primarily used to model the information in the factory design process and to support the process itself. Autodesk Vault provides the management of the CAD files, including the versioning of overlay ('xrefs') files. The demonstrator shows that Aras Innovator (or indeed any general purpose PLM system) can represent the information needed on levels of granularity ranging from 'documents' (large data sets), to objects and properties of these objects. Search and retrieve, access control, version and configuration management, multi-user environment, and scalable architecture are key benefits of a PLM system from an information integration and management point of view. However, the PLM system does not provide any access to the internals of files, e.g., geometry elements in CAD-files, cells in a spreadsheet or paragraphs in a text document. Some of this functionality is supported by Autodesk Vault, but it is not immediately possible to link a solid in a CAD-file to its requirements in a text file.
The purpose of the prototype was to show how the capabilities of commercial software applications can be used to support the factory design process in a relatively short (one to five years) time perspective. The prototype shows that the applications in each layer do a quite acceptable job; however, the applications are still lacking integration capabilities, especially on a finer granularity than that of a file.
The integration between the AFM and the CAD-layers works well for files, file references, and properties. We can for instance define a property (as a name, value pair) in Vault, view and modify it in AutoCad, and when the file is checked back in to Vault, we can search for the new value, modify it again, etc. In a similar way we can modify, e.g. file references.
In the prototype there is only a simplistic integration between the PLM layer and the CAD layer, which allows the transfer of a Machine Data Card. However, since Aras (like most PLM systems) provides an API giving access to all server functionality, it is straight forward (but possibly time consuming) to create any integration that is needed to connect to any application. The question is then rather what to store and maintain in PLM vs. CAD (or Aras vs. AutoCad). There is obviously no clear-cut answer to this but some indications as to when the item should be stored in PLM are:  The item is version controlled, e.g., to maintain history of released versions.  The item is access controlled, e.g., only some users may update a property, but all may read it.  The item should be globally searchable, e.g., to find any production equipment of a certain type. Note that we include reporting here, e.g., to generate a list of all machines being installed during the last year. If an item is represented in several applications, it is generally important to identify the application owning it. Duplication of data should be avoided, and if necessary, the synchronization paths must be well defined.