A Knowledge Based Collaborative Platform for the Design and Deployment of Manufacturing Systems

. he PLM systems do not provide any link to actual performance indicators, related to cost, time, and quality parameters. This paper describes a collaboration platform, based on a semantic core that expresses knowledge about Products, Processes and Resources. The platform is internet based, connecting engineers in the extended enterprise with shopfloor personnel. The concept is based both on a series of distinct components and elements comprising the knowledge base, and on a set of software agents. The latter are interfaced with a set of Computer Aided (CAx) systems and provide decision support capabilities for the design of a production line.


Introduction
Most industrial sectors strive to find methods to reduce costs, time-to-market as well as to improve quality and expand market opportunities [1]. Production line design and development can be regarded as one of the most challenging decision-making processes, since it is affected by numerous design factors and criteria. Furthermore, it involves collaborative work carried out by several engineers such as process, industrial, and manufacturing equipment engineers [2]. Thus, different models, methods, techniques and technologies have been researched and developed to aid engineers in managing the complexity of production line design and development. Khan and Day in 2002, introduced a knowledge-based conceptual design methodology for single, multi-and mixed-product assembly lines; this methodology, based upon a selection of a suitable assembly systems can decide on suitable cycle times, parallel work station requirements, and parallel line implementation achieving an economical number of work stations [3]. Several system analysis methods were developed for assisting engineers with the optimization of their design, namely in [4,5] where dynamic programming algorithms and Taylor series expansions were used in order to determine values such as the number of machines for each station and analyse the average steady-state throughput of cyclic production lines, respectively. Two noticeable examples of integrated simulation models, in production design processes, comprise a method of the simulation tools being used as modules for JIT manufacturing design [6] and an integration framework of analytic and simulation tools for the assembly line design [7]. A later approach has discussed the implementation of a web-based workflow management system for integrated production engineering, where the workflow of a production engineering project could be configured within a BPEL Engine layer [8].
These simulation tools can demonstrate the behaviour of production lines, before their implementation, and contribute to a reduction in the development lead-time. However, they are subject to the availability of detailed engineering information, before useful simulation models for analysis can be developed. Consequently, these tools are usually utilized during the final stages of the design process in order for the configurations of design solutions, already planned in detail, to be verified [2], whereas analytical methods are applied during the conceptual design stage, when design solution outlines are constructed [12]. Furthermore, these design methodologies do not consider the collaborative aspect of the design and the development processes, meaning that similarly to the product development process, the production line design process is a very knowledge-intensive and collaborative task that involves different stakeholders and knowledge bearers [9]. While knowledge-intensive collaboration has emerged as a promising discipline for dealing with the modelling and decision-making processes, in distributed product design systems, the same cannot be said for the design of manufacturing systems and production lines [10]. However, with the advent of the Internet, software frameworks will continue being developed for improving the ability to represent, capture and reuse design knowledge [11].

Platform Architecture
The proposed platform is expanded into four main domains; the Execution, the Workflow, the Interface and the Knowledge domain ( Figure 1). The Knowledge and Workflow domains include the so-called "Knowledge base", which is a semantic description of the acquired knowledge and workflow structure of production design processes, comprising production data structures as well as information about the production parameters. Further details concerning the Knowledge domain will be given in the next section. The Execution domain includes software agents and applications that directly assist the production design participants in performing various tasks, with reference to project execution and project management. The latter is supported by separate agents (Workflow agents), which inform engineers of their task (e.g. regarding the location of necessary input data files) on the basis of a project's latest progress and keep track of it (through the Workflow domain). The execution of tasks is supported by specific agents that, depending on the expected results of a task, provide links to either webservices working as tools for specific steps (e.g. for line balancing, cycle time calculation) or translation services, regarding the possible incompatibility of file formats (e.g. translation of proprietary file formats to open standard formats, such as PLCopen or STEP).

Fig. 1. Specific domains of the proposed platform
The Engineering data represent a cloud service in the form of an Infrastructure as a Service (IaaS) that includes a common database. It is connected to the knowledge repository and the physical data repositories placed in each stakeholder's facilities. When data have to be shared, the Workflow agents use the Project management information model, in the Knowledge base, for the calculation of the access rights that either provide the relevant link to the file or not. Finally, the interface domain includes all the necessary interfaces among the SW agents, the web-based services and the production design participants that work in the various projects.

Knowledge Structure in the Extended Engineering
The structure of the information and consequently the formation of knowledge, as regards production design and deployment, was realised with the use of an ontology modelling and it was based on two main requirements: • The model that will be used should have a very definite set of concepts including the relations between the concepts. • The concepts should be as generic as possible in order to satisfy possible differences within the organisations in extended engineering.
These requirements are somewhat contradictory, since the greater the depiction of concepts, the lower the generic character of the model. Therefore, the modelling was performed on the basis of cases created by industry partners that served as Original Equipment Manufacturers (OEM), production system Integrators and parts/ equipment suppliers.

Product-Process-Resource Model and Relevant Files
The Product, Process and Resource views are common terms in PLM systems and represent the different views that engineers have on CAx files during the production design execution. In the proposed platform, the first sets of concepts of the Product-Process-Resource (PPR) include the modelling of the actual digital, production planning related data. The main concepts here are Product, Process and Resource. The modelling of these concepts derives from the higher level structures of relevant files, used by commercial CAx products and STEP Part 21, at the extent of their being considered consistent with each other. The selection of the CAx tools was based on questionnaires, delivered both to OEMs and SMEs, as well as a production system integrator. The lower levels of the structures were not used since there were inconsistencies between the different CAx products' file structures. In cases that information from the lower levels of a file's structure needs to be extracted, e.g. for the identification of process times from a CAM file, this can be done through the parsing of files or the direct input by the user of the relevant attribute values through a Graphical User Interface.

Fig. 2. Product-Process-Resource model
The product data have their own structure that links them to the part data with a simple object relation. The processes can also be depicted as a CAx file, while the resource files are also described as product data through a simple "has" relation. The relevant data objects are not only CAx files. Therefore, a special concept named Des-ignDataObject, was defined as shown in the figure below. The specific components of this concept represent documents, spreadsheets and files, relevant to one or more tasks of the design process and the creation of various documentations. The specific concept also includes XML files that can be manufacturing related, such as machine controller programs (e.g. PLCopen XML format) or they can express process sequences or even support business processes such as tendering (selection of suppliers).

Workflow and Human Resources
This section describes the main concepts that are related to project workflow management and human resources. The term human resources here is used to describing the relevant actors participating in the design of a production system. The main concept, regarding project workflow management, is the Project Element, which has as subclasses the project, the phases and tasks of a certain project. The project individuals coming from the Project subclass serve as a reference that lasts throughout the design and deployment phases. The data attributes can be filled in through a web-application that works by means of collecting all the initial specifications for the design project (e.g. by an OEM to the Integrator). Each project element is linked to another through relations, namely the hasTask or hasPhase. When a new project concept is created, the individuals of the Phase concept are already set: Planning Process/ Layout, Planning of tools and equipment, Line balancing, Specification of tools & equipment, Purchasing of equipment, Realisation/Ramp up.

Fig. 4. Project elements' concept
The tasks of each phase can also be copied from the previous versions on the basis of similarity measurements, regarding the initial specifications of the project. Each Project element is linked to one or more Design data object(s) (described in the previous section) through relations such as hasInput and hasOutput. Therefore, the workflow also represents a data flow in the sense of certain files, required as input or output from each phase.
As regards human resources, the main concept connecting people to tasks is that of the Role (Figure 5). Each person is inserted into the platform as an Actor, a concept which includes information with reference to a person's experience and background. At each time instance of the project, the information about a person's involvement in the project is described. Furthermore, the most relevant people that can fit in a role can be identified by simple queries that can be performed by SW agents. In the following section, the technological implementation that allows the mapping and the data exchange between the central ontology and the local data bases of the project's stakeholders is presented.

Knowledge Base Mapping
Although the models presented fulfil the requirements of the end users, the elements that represent the actual files, used by engineers, should be somehow linked to the locations of the actual data. This section describes the way that the ontology elements' structure described in section 3.1 can be mapped to the local database structures of the Fig. 6. Knowledge base mapping various stakeholders, participating in a collaborative project. The knowledge base mapping refers to the linking of the corresponding elements and the data exchange between the central ontology and the local data bases of the project stakeholders. The implementation is made through a middle step ( Figure 6, Connector), in the Jena framework (Java). Via Jena, all the relevant ontology objects can be linked to the corresponding files in local data repositories. The persistence layer is the main link between the different objects, while the service layer is where different web-services and agents can interact with the ontology model and in the course of it with the relevant data attributes, files etc. Since the ontology describes a number of projects (complete and on-going), the relevant concepts are not used as they are, but are automatically recreated each time that a new project is set up. These concepts are included in separate OWL files, connected to the main ontology through uniform resource identifiers (URIs). This helps boost the editing, reading and reasoning functionalities of the model. The re-instantiated concepts include all the PPR models as well as the relevant tasks, roles etc.

Case Study
In order for the utilization of the proposed platform to be demonstrated, a case study is presented below. The actors belong to a system integrator that has been commissioned by an OEM to design a new line.
One of the platform's main functionalities is the use of web-based applications that can interact with the ontology. In this case study, the application considers the initial rough line balancing from an assembly line that has to be performed at the initial steps of the line balancing phase. The application can be provided as a link to the relevant actor that has the corresponding role. The application reads the ontology of the project and calculates the cycle time using data from the project's instance (individual). More specifically, the application automatically uses capacity, working days, shifts and working time per shift values (see Figure 4) and provides the value of the cycle time. Then, the user is requested to input the number of processes, including their expected times as well as any alternatives that derive from the use of different equipment. This can be done through a common web-based interface, where the information from the engineer is sent to the application through XML (Figure 7). Finally, the application forwards the results, which the user can either accept or try using different data, or even inform the relevant actors that the setup has to change (change request). In this case, the platform agents can inform the other participants of the change requests, by reasoning through the hasInput and hasOutput semantic relationships for the identification of the tasks that provide the input to this task, the relevant Roles and subsequently, the Actors.
Since, the initial rough process times have been inserted into the line's description, another actor can use the semantic repository available in order to identify appropriate equipment for the rest of the processes (e.g. electric screwdrivers). The platform uses a semantic Rule that groups from previous projects processes similar to the ones that the user has defined based on their name (e.g. transmission tightening), the type (e.g. manual) along with their corresponding duration. After the grouping, a query that provides the resources belonging to the similar processes is executed. The engineer can now select the equipment that can be reused in the new project and automatically, the project's data including the line's cost are updated in the repository.

Conclusions
In this paper, there is a presentation of a collaborative platform that uses an ontology model for the description of different engineering files, business processes and human resources. The ontology serves as a communication layer between the different organisations, within extended engineering and can be handled by different SW agents as well as by engineering related web-based applications. The ontology is used not only as a representation of the engineering processes but also as a description and a mapping between engineering and business processes, which can be regarded as an extension of the current PLM approaches to production design. It is anticipated that this approach will enable the boosting of collaborative processes, including project management and data exchange between different stakeholders. Furthermore, the ontology can be used for the storage of knowledge with reference to certain business and engineering processes that can be identified by SW agents in new projects. Possible challenges that should be addressed in the future are the access rights management, concerning files shared by different companies as well as the support for the exchange of open standards by commercial CAx tools. Moreover, ontology related technologies need to be further evolved as regards their integration with various database technologies. Incorporating human-centred interface technologies, such as Augmented and Virtual Reality into the platform and expanding the business processes could be two very interesting paths to be explored in a future study.