Göknur Sirin

Fabien Retho

Bernard Yannou

Martine Callot

Philippe Dessante

Eric Landel

Multidisciplinary Simulation Model Development: Early inconsistency detection during the design stage

Keywords: Collaboration, Multidisciplinary Modeling & Simulation, Model of Intention, Model-Based Systems Engineering, Ontological Engineering, Consistency Management

come

Introduction

To represent vehicle behavior accurately in a given field situation, simulation models are created by integrating different simulation models of the sub-systems within the vehicle, such as chassis, engine, transmission, etc. These sub-modular system models are referred to as domain models. The simulation model development process involves a number of parallel or/and sequential activities in which experts in different disciplines create or reuse domain-level models to construct a full vehicle model [START_REF] Sirin | A Model Identity Card to Support Simulation Model Development Process in a Collaborative Multidisciplinary Design Environment[END_REF], [START_REF] Branscomb | Supporting Multidisciplinary Vehicle Analysis Using a Vehicle Reference Architecture Model in SysML[END_REF]. This is particularly challenging for the design of multidisciplinary systems in which components in different disciplines (e.g., mechanics, structural dynamics, hydrodynamics, heat conduction, fluid flow, chemistry, or acoustics) are tightly coupled to achieve optimal system performance [START_REF] Branscomb | Supporting Multidisciplinary Vehicle Analysis Using a Vehicle Reference Architecture Model in SysML[END_REF]. Each disciplinary model can be developed and evolve following its own semantics and development tools at different rates [START_REF] Zhang | A Model Management Approach for Co-simulation Model Evolution[END_REF]. Several problems were thus observed during a preliminary study that the authors conducted in the simulation model development practices of both the automotive and the aeronautic industries [START_REF] Sirin | A Model Identity Card to Support Simulation Model Development Process in a Collaborative Multidisciplinary Design Environment[END_REF], [START_REF] Retho | Le modèle d'intention: Un concept clé entre architecte et expert pour la conception de systèmes complexes[END_REF]. From these observations two major worlds were identified: (a) the system world, including the Systems Architect and the Technology Provider for all types of contracting and innovation issues, and (b) the model or physical world including the Model Architect and the Model Provider for model design and development (see Fig. 1).

Fig. 1. Collaboration between major M&S actors

Today one of the problems in this collaborative environment is that models are usually considered as available, ready to be integrated or requested directly from an expert (e.g. model provider) without specifying any method. However, the technology or service provider's engineering analysis model is most often in a Black Box (BB) format to preserve intellectual property (see Erreur ! Source du renvoi introuvable.1). BB models can be interacted with only through the inputs and outputs of a well-defined interface. The challenge in using a BB model is taking into consideration the number of distinct interface issues, parameters, or messages that have to be passed among the components [START_REF] Sirin | Value Creation in Collaborative Analysis Model Development Processes[END_REF]. Another problem is that the supplier is not integrated in the model design and specification phase, and the OEM has no access to the simulation model development activity. This decoupled way of working may create unnecessary iteration during the model integration phase, often resulting in increased product development lead time and cost. In our experience, specifying a simulation model is not as trivial as might be expected; it is an important yet undervalued practice. Hence OEMs must establish an effective methodology, based on different viewpoints of the actors, to create a credible simulation model, while avoiding project delays and unforeseen rework cost by detecting any inconsistency problems before building costly simulation models. In systems engineering practice, inconsistencies manifest in a variety of forms: violation of well-formedness rules, inconsistencies in redundant information, mismatches between model, their interfaces and test data, and not following heuristics or guidelines. In current practice, most of these inconsistencies are only identified during reviews that are part of the verification & validation activities. In between these reviews there is a possibility of decisions being made based on inconsistent information and knowledge, which can lead to poor outcomes and costly rework. It is impossible to say whether or not a system is fully consistent but at least we would like to show by this paper that some inconsistencies can be detected as early as possible during the design process. Typically, the earlier an inconsistency is identified, the cheaper it is to resolve. A recent paradigm shift in systems engineering known as Model-Based Systems Engineering (MBSE) has the potential for the process of identifying inconsistencies to be performed in an automated fashion. Automated and computer-assisted methods are important enablers for more frequent inconsistency checks and therefore towards continuously verifying & validating systems [START_REF] Herzig | A Conceptual Framework for Consistency Management in Model-Based Systems Engineering[END_REF]. Consistency management in MBSE has been studied before [START_REF] Schätz | Consistency In Model-Based Development[END_REF], [START_REF] Andre | Checking The Consistency Of UML Class Diagrams Using Larch Prover[END_REF] and [START_REF] Herzig | A Conceptual Framework for Consistency Management in Model-Based Systems Engineering[END_REF]. A review of the related literature reveals that this is still an open challenge and has not yet been investigated at a fundamental level within the context of Model-Based Systems Engineering (MBSE). Research efforts mentioned in the related literature discuss several methods to check for and potentially resolve inconsistencies that can occur within and across models from different domains. Unfortunately, most of the current work is incomplete and only considers specific types of inconsistencies. This is one of the reasons why some of them do not scale. Detecting inconsistencies outside the scope of logic and mathematics requires additional information to be present in the system. Therefore, additional, computer-interpretable rules must be defined in the form of, e.g., description logic or meta-models. These must include domain-or application-specific rules. More rules may be necessary to define the relationship between two or more models affecting application or domain-specific properties [START_REF] Blanc | Incremental Detection Of Model Inconsistencies Based On Model Operations[END_REF]. The aim of this work was to reduce late inconsistency detection by ensuring early stage collaboration with a clear simulation model request and design artefact negotiation. To this end, this paper proposes an early-stage multidisciplinary simulation model design methodology inspired by Model Based Systems Engineering (MBSE) [START_REF]Systems engineering handbook[END_REF]. Proposed early stage model request package consists of a meta-model called MIC for interface inconsistencies detection and a Model of Intention (MoI); an executable behavioural model to illustrated expected model's behaviour. This paper is organized as follows: in Section 2, we give a general literature review on the role of different actors and the management of their views and viewpoints; in Section 3, we introduce our methodology of early-phase simulation model design, explaining the formal architecture design, and MIC and MoI concepts (the reader will find in reference [START_REF] Sirin | A Model Identity Card to Support Simulation Model Development Process in a Collaborative Multidisciplinary Design Environment[END_REF] and [START_REF] Retho | Model of intention: A concept to support models building in a complex system design project[END_REF] a more detailed state of the art in meta-model and Model of Intention); Section 4 introduces an industrial case study with its validation protocol, and our conclusion and future considerations are in Section 5.

State of the Art

Related Research Methods and Industrial Projects

The approach proposed in this paper is developed to support the building of a multidisciplinary virtual product (i.e. simulation model). A virtual product is a global model of a future product (car, train, aircraft, helicopter, etc.) that can be simulated to predict its behavior with an estimated accuracy and validity domain. Numerous methodologies that contribute to the virtualization of design with models and simulations have already been developed [24, 25, 26, and 27]. Increasing vehicle complexity requires an ability to manage development decisions proactively, and this can be accomplished through a Systems Engineering RFLP methodology [START_REF] Kleiner | Model Based Design with Systems Engineering Based on RFLP Using V6[END_REF].

Fig. 2. RFLP Methodology

The RFLP model describes the left-hand descending branch of the "V-Model". Based on the well-known V-cycle design process, RFLP allows concurrent engineering to coordinate the separate activities and views of distributed design teams. In this context, a viewpoint describes a particular perspective of interest to a set of stakeholders; a view is a stereotyped package said to conform to a particular viewpoint [START_REF]Systems Engineering Fundamentals[END_REF] (see Fig. 2). R refines Requirements views, the Functional View (F) defines what the system does operationally with a given scenario (intended use, purpose, internal functions), the Logical View (L), or logical/organic architecture defines how the system is implemented (i.e. its breakdown structure, block diagram, logical interfaces, and logical connections). The Physical View (P) defines a virtual definition of the real world product. In this paper, we customize these different views based on our needs. Thus a complex simulation model development process can be described in the context of four interrelated types of knowledgefunctional, structural, behavioral, and physical knowledge or views. These views contain in turn numerous sub-views; the functional view contains requirement, system architecture and operational views. Structural knowledge includes definitions of the form, and dimensions of the artifact, its constituent components, and their arrangement and connections to each other. A structural description is sufficient to construct the artifact (simulation model). It includes the necessary information about the artifact's explicit parameters, which a designer determines directly in order to generate a physical solution to an abstract problem. Behavioral knowledge includes the description of the artifact's potential behaviors in response to its environment in a given scenario (see Fig. 3).

As vehicle systems are continuously increasing in complexity, it is essential for there to be a process flow to handle the modeling of the vehicle system from beginning to end [START_REF] Branscomb | Supporting Multidisciplinary Vehicle Analysis Using a Vehicle Reference Architecture Model in SysML[END_REF]. [START_REF] Roques | MBSE with the ARCADIA Method and the Capella Tool[END_REF]. ARCADIA is based on architecture-centric and model-driven engineering, and was supported by the use of "standard" language such as architecture Framework (e.g. NATO AF or NAF), and SysML/UML. However, ARCADIA promotes driving engineering no longer by requirements only, but mainly by functional need analysis (and also operational analysis) [START_REF] Roques | MBSE with the ARCADIA Method and the Capella Tool[END_REF]. The industrial method stated does not enable us to design a simulation model world. We sought to pull and transform the necessary system-related information such as system requirements, functions and operations to design a simulation model in a model world.

Thus the transition from system models (system world) to behavioral physics-based modeling (model world) should be structured first with an architecture framework, and then supported by information flows between different design actors (see Fig. 3). However, today's internal communication is ensured by informal knowledge sharing, and has become an error-prone activity, because different disciplines often use different vocabularies. Semantic differences can cause misunderstandings among these actors [START_REF] Sirin | A Model Identity Card to Support Simulation Model Development Process in a Collaborative Multidisciplinary Design Environment[END_REF]. Today there are two main actors in a model development environment: System Architects and Domain Model Providers (i.e. Model Suppliers). System Architects are the sponsors of model development activity. They define the technical and project-based constraints. They also define an operational scenario, some decision criteria, and provide a system architecture. By contrast, Model Providers are the domain experts who build models with their specific domain knowledge (see Fig. 3). One of the gaps that we noted during our research investigation in the OEMs is that there is no clear and formal model specification agreement between System Architects and Model Providers at the early model development stage (or conceptual design phase). In addition, most of the time, the interaction of these two actors can create a bottleneck for communication because they do not have the same levels of understanding. One useful result of this work is that it creates a more formal and clearer model request for the domain model providers, so as to obtain the right model at the right time. This transversal view from Functional to Physical View has to be managed by a new actor in the collaboration we name the "Model Architect". Model Architects have a multidisciplinary vision of a product, and simulation knowledge. They also have a deep understanding of both the system-level requirements for the vehicle model, and of how their models have to interface with other domain models (see Fig. 1). There are multiple activities involved in the Model Architecture business cycle, such as:

• understanding the system world requirements, and interpreting and translating these requirements in the model world,

• analyzing or evaluating and selecting the architecture, and • communicating with system architects and multiple domain-level model providers. These activities do not take place in a strict sequence, and there are many feedback loops as the multiple stakeholders negotiate among themselves, striving for consensus. The Domain Expert (Model Supplier) also plays a fundamental role, with expertise, experience and knowledge to support the Model Provider's final model-building and delivering activities (see Fig. 3).

The collaborative multidisciplinary simulation model development process creates a response to the request of the System Architect who seeks elements to analyze architecture for a design choice. The intent of the System Architect is to evaluate whether system requirements are foreseeably satisfied, based on the existing knowledge of the system to be. During this conceptual design stage, the first information flow provides the following elements: an architecture description, variables of interest, constraints, and scenarios with expected accuracy from System Architect to Model Architect (see Fig. 3).

a. Architecture Description The system is functionally and logically described. The logical description covers the topological structure (existing connections among system components, such as SysML Internal Block Diagrams) and other properties specific to the nature of the component (e.g. density, electrical or thermal resistivity, conductivity, chemical nature). When the System Architect considers several alternatives, each one comes with its own architectural description [START_REF] Sirin | Value Creation in Collaborative Analysis Model Development Processes[END_REF][START_REF] Kleiner | Model Based Design with Systems Engineering Based on RFLP Using V6[END_REF].

b. Decision Criteria

A variable of interest is a characteristic of the system (related to its behavior, its structure or to any other viewpoint on the system) that interests the System Architect. The variable of interest can be a scalar, a multidimensional vector, or a field in the response space. Noise comfort in a car is one such variable.

c. Constraints Technical Constraints:

Unless the System Architect is looking for preliminary or exploratory results, he sets boundaries to surpass (e.g. performance, safety and environment) or to respect (limits) in the response space of variables of interest. The noise level that causes hearing damage is one such limit.

Project Constraints:

Project cost and time to development are considered as project constraints.

d. Scenarios Multiple scenarios can be proposed to fit the complexity of the vehicle and the different mission profiles, such as standardized urban, extra-urban, or mixed fuel mileage for a car or in an operational concept (e.g. flight profile typical for a short-range commuting airliner).

e.

Expected Accuracy

The applicability of any model depends on the accuracy and reliability of its output. However, because all models are imperfect abstractions of reality, and precise input data are rarely available, all output values are subject to inaccuracies. Accuracy is the closeness of the agreement between the measured and true values. High accuracy implies low error. Thus depending on the maturity of the design and design specification supplied to the Model Architect, the System Architect may insist on having a high degree of confidence in the model result produced [START_REF] Hester | Epictemic Uncertainty Analysis: An Approach Using Expert Judgment and Evidential Credibility[END_REF]. Second information flow from Model Architect to Model Provider contains the following elements: earlystage simulation model design consisting of a formal architecture representation, an MIC and a MoI. The Model Identity Card (MIC) and Model of intention (MoI), concepts that we will describe in the next section, were developed with the aim of supporting structural and behavioral views of the simulation model design phase (see Fig. 3).

PROPOSED METHODOLOGY

In this section, we define the MIC and MoI concepts separately, and go on to propose the mixed method.

MODEL IDENTITY CARD (MIC)

Designers and suppliers need to obtain an effective knowledge exchange through a shared vocabulary. Providing a common vocabulary for the design and development actors can help communicate fact-based decisions in a maker's assessment of the credibility of M&S results [START_REF] Herzig | A Conceptual Framework for Consistency Management in Model-Based Systems Engineering[END_REF]. The ability for users to select from a list of options is an immensely important capability. By restricting large groups of users to the same vocabulary and set of options whenever possible, inconsistencies arising from miscommunication or misinformation can be reduced significantly [START_REF] Sirin | A Model Identity Card to Support Simulation Model Development Process in a Collaborative Multidisciplinary Design Environment[END_REF]. There are some recent, similar research efforts in ontologybased systems engineering. The most extensive prior research on characterizing a model's behaviour in engineering analyses was that of Grosse et al. [START_REF] Grosse | Ontologies for supporting engineering analysis models[END_REF]. This ontology draws upon some of the analysis modeling taxonomies and concepts presented by Noy and McGuinness [START_REF] Noy | Ontology Development 101: A Guide to Creating Your First Ontology[END_REF]. They organize the knowledge of engineering analyses models into an ontology, which includes both metadata (e.g. author, documentation and meta-knowledge, such as model idealizations and the corresponding justifications). A similar, though less extensive metamodel for engineering analysis models has been developed by Mocko et al. [START_REF] Mocko | A Knowledge Repository for Behavioral Models in Engineering Design[END_REF], but these taxonomies do not include detailed model behavior characteristics, or any model validation and verification attributes such as NASA's credibility assessment [START_REF]Standard for models and simulations National Aeronautics and Space Administration Washington, DC 20546-0001[END_REF]. Based on the standards and methodologies described above, we developed the MIC metamodel likely to be applicable to any numerical model in the context of vehicle manufacturer with some domain specific customization. The MIC metamodel includes some important refined characteristics of engineering analysis models (object) such as modeling assumptions and interface specifications.

The objective of MIC is to simplify analysis model specifications, sharing and reducing ambiguity, and to reduce the amount of rework caused by interface inconsistency between domain models. MIC assigns a model to one of two main classes: an object with four sub-classes (Object, Methods, Usage and Model Quality) includes the attributes of the model, which are stored in the MIC Properties. The second tab (Interface) includes the attributes of the Ports that designers define (see Fig. 4 and Fig. 5). The semantics and definition of the interfaces need to be accurate and complete because the communications within model components or between model components and the outside environment have to be connected with well-defined interfaces [START_REF] Mocko | A Knowledge Repository for Behavioral Models in Engineering Design[END_REF]. The interface does not contain any information about the internal behavior of the component. Instead, the interface exposes the key parameters, while encapsulating the implementation of the model, which defines the internal behavior of the component.

The following are some important characteristics of the MIC Interface Concept (see Fig. 5):  Each Model, and consequently its MIC, can have several Ports of different Domains (e.g.

Mechanical, Electrical, Hydraulic, and Thermal).  Each Port is composed of multiple Variables.  Variables represent Efforts (voltage, temperature, force, torque, pressure) & Flows (current, entropy, linear velocity, angular velocity, volumetric) based on the law of energy conservation in a physical system [START_REF] Karnopp | Analysis and Simulation of multiport Systems. The Bond Graph approach to physical systems dynamics[END_REF].

MODEL OF INTENTION (MoI)

The MoI is a model-based approach to request and specify models for a given scenario [START_REF] Retho | Model of intention: A concept to support models building in a complex system design project[END_REF], [START_REF] Retho | Le modèle d'intention: Un concept clé entre architecte et expert pour la conception de systèmes complexes[END_REF]. It enables a model supplier and technology provider (expert) to propose an adequate model. This concept is innovative in the design field, but comparable in some respects to the System Specification Model (SSM) [START_REF] Rtca | Model based development and Verification[END_REF], Simulation Conceptual Model (SCM) [START_REF] Dod | Verification, Validation and Accreditation Recommended Practice Guide (MSCO VV&A RPG) Glossary[END_REF] and Prescriptive Model [START_REF]IEEE Standard Glossary of Modeling and Simulation Terminology[END_REF], because MoI expresses an expected behavior of a simulation model with a specific estimated role model. The objective of MoI is to effect the transition from the real world to the virtual one in the MBSE approach. The method developed to support the MoI is based on system Interactions and Impacts (I&I). The I&I concept is to analyze a system by way of its complexity, which causes inter-system multidisciplinary interactions. The interface specifications from I&I supports the MoI building with port inputs, outputs and parameter information detection for a given scenario. Technically, the MoI is a model integrated in a multidisciplinary executable behavioral global model of the system under design. The objective of this global model is to show expected behavior of the artifact, which is represented by the MoI. The model's behavior includes performance requirements and dynamic tendencies, and guides the model providers and experts. As shown in Fig. 6, from left to right, the method is explicitly decomposed into the real and virtual system specification and realization. The method is initialized by a design question that drives the model request. A first behavioral and executable model was developed in Modelica language that promotes energy exchange in a powerful way [START_REF] Chan | The state of the art of electric and hybrid vehicles[END_REF]. To support propulsion system problems, we have developed a Modelica library to model different architectures easily. The methodology ends with the performance of simulations. According to the scenario, some results of these simulations can be selected to be sent to the system architect to support decisions.

PROPOSED METHODOLOGY: A MIXED APPROACH

The MIC and MoI concepts deal with the same objectives: reducing the knowledge gap between designer and model provider. However, they have complementary concepts for creating a complete model request package. The main difference is that MIC is a formal vocabulary and a MoI is an executable behavioral model.

The MIC tackles model specification with interface characterization issues, but its weak point is its low capacity for representing behaviors. These complementary characteristics allow a robust model request packaging such as (see Fig. 7 and Fig. 3 As we stated earlier, the challenge in using the suppliers' BB model is to take into consideration the number of distinct interface issues, parameters, or messages that have to be passed among the components. However, with our proposed clear model request package and formal model architecture design, integration of each BB model can be ensured.

As illustrated in Fig. 7, with such a model request package, expert and model supplier can manipulate the MoI observable parameters so as to be able to understand the requested models' expected behaviors for a given scenario. As illustrated in Fig. 8, the major role of the System Architect is to specify the system to be modeled and supply the essential system-related requirements to the Model Architect (see Fig.

CASE STUDY

In this section, we illustrate the proposed method (see Fig. 8) with an industrial case study. This case is built around a hybrid parallel propulsion system that contains five sub-systems (see Fig. 9). This architecture can be installed in various types of vehicle, such as a car or even an aircraft, and allows the product to having an additional power source when its mission requires it [START_REF] Chau | Overview of power management in hybrid electric vehicles[END_REF] [20], [START_REF] Mi | Hybrid Electric Vehicles: Principles and Applications with Practical Perspectives[END_REF][21] and [29][28]. The scenario proposed by the system architect is to analyze and pre-size the new electric propulsion chain (technical objective) (see Section 2). Observables are the mass of this additional chain and the advantages in terms of pure power addition on a sizing objective mission (decision attribute). To obtain these observables, the system architect makes a requests to the model architect for a global model which that can simulate the entire hybrid parallel propulsion system behavior, including models of the electric machine motor and battery. These two models must be as possible in line as possible with current technologies tendencies trends. The expected accuracy is to be around a 10% rate of error for each observable. This section describes all the inputs that the system architect delivers to the model architect to complete his request (see Section 2). As visible shown in Fig. 9, the proposed architecture requires needs to be associated to with a mission objective and a control. The mission objective is decomposed into five phases with different durations and required powers (P_requested). The control is defined with a three-mode strategy based on power exchanges ( :

First Step: Inputs from the System Architect

 Mode 1:  ;  Mode 2:  ;  Mode 3:
; Power requested cannot be satisfied  mission fail.

The other inputs corresponding to existing and already specified components are the thermal propulsion chain and the gearbox models. This hypothesis is made in order to propose a reengineering problem, which reduces the design space and simplifies our demonstration.

Formal Model Architecting

The MoI uses the SysML modeling convention by default [36]. However, many engineers today are still unfamiliar with SysML, and the cost of training and licenses needed to put SysML tools into practice across large engineering teams can be prohibitive. In this paper we therefore adopt a different approach: rather than assuming that the structural model design is possible with a SysML environment, we prefer to use a system engineering tool named arKItect, because it enables us to specify the system architecture easily in a hierarchical manner. In this tool, the functional flows describe the interactions both between the system functions and between the system and the external environment. The flows can be either data or physical flows. Based on a powerful hierarchical type definition, arKItect lets us design our own metamodel very easily using a given metamodel structure: objects, flows and their composition rules (see Fig. 10) [9]. The design of formal system architecture is one of the activity areas of Model Architects (see Fig. 8) [36].

A part of the formal model architecture design is illustrated in Fig. 10. For clarity, we identify only one physical connection between Electric Motor and Battery sub-models. The attributes we use in the MIC GUI reduce the ambiguity and misunderstanding between model architect and model provider. This possible communication problem has an adverse effect on model quality and decision. Some interoperability problems stemming from a misunderstanding of software versioning, undated libraries and model units, can be mitigated by using an MIC. The model provider also fills out some important attributes before pointing out the relevant model and sending the complete MIC to the model architect.

As shown in Fig. 11 and Fig. 12, the model provider must fill in important attributes, such as the name of the method that the model provider used to develop the model, and the model precision, solver name, dimension, time step, software tool name, versioning etc.

Fig. 12. Model Specification with MIC

As illustrated in Fig. 8, the model architect characterizes each incoming and outcoming port of the related sub-models and their connections with each other. Each port may have more than one variable, and we need to define the nature, direction, units, size and min/max value of each variable (see Fig. 7 and Fig. 8).

Fig. 13. Interface Specification with MIC

Finally, the MIC contains various correctness checks for interoperability problems such as domain model software names, versions, models' min/max values, units, the direction of a causal connections, models' accuracy levels, etc.

First Step : MoI Building

In the MoI methodology, four types of model can be requested, on two axes: new model or modification of an existing one; system model or environment model. In this demonstration, a request for two new models is being made. The first step in the MoI building is to propose an initial first model of architecture. Considering the gearbox and thermal chain already specified, models from the system architect are used. Control and mission models are customized with existing models of the specific propulsion system library that we have developed for MoI concept building. All requirements, which can be modeled as inequalities in each model, are aggregated under a specific model to stop simulation if an inequality is false.

With the MIC specification, entire requested model interfaces are defined. In that way, it is possible to create models with ports and parameters directly in Modelica. These two new blank models (no equation inside) are introduced in the global architecture model (see Fig. 14) Fig. 14. Global model including electric motor and battery blank models

The next step in the MoI approach is to introduce simplified behavior that consists in connecting inputs and parameters to outputs, inside blank models.

For the electric motor (EM), two simple equations with two new factors proposed as parameters enable us to consider the two observables ( :  The electric motor's main function is to deliver rotational mechanical energy from electrical energy.

In simplest modeling, the efficiency ( of this conversion is considered as a new parameter.

(1)  The electric motor mass is a parameter, as mentioned in MIC. A simple power density parameter is proposed to relate mass and maximum power.

(2) These two behavioral equations are quite simple to introduce because they are based on the function or mandatory parameter, and are realistic because factor values can be specified with the help of the literature. For the battery (B) it is only the energy transfer from battery to consumer (EM) that has to be modeled. This discharge is the main function because the loading function is not used, so not modeled:

 The battery main function is to deliver electrical energy from chemical energy. The efficiency ( of this conversion is considered:

(3)  The battery mass parameter enables us to determine the initial energy quantity, considering that the battery is fully charged at the start. To determine this energy, a simple energy density parameter is proposed: (4) The real behavior is the energy consumption, which depends on the requested power. Based on the energy definition, we propose modeling the energy evolution with:

(

With the parameters in Table 1, numerous simulations can be performed. These induced results support the supplier team with additional behavioral information, which enables suppliers to hold discussions in order to propose advice on technologies to be introduced in their model of realization. For example, for the electric motor, the choice of a synchronous or asynchronous motor can be the subject of such advice. Simulation also allows the visualizing of system limits with requirement checking. Relatively, the difference of 20 equations shows the gain in complexity.

Battery model comparison

The battery behavior needs to be studied alone owing to its dependency on the electric motor model outputs.  at , a long iso-power request is finished. The different models show different SoC for the battery, the use of the MoI shows a deeper discharge than the MORs (Techno 1 and Techno 2);  at , power requested is too high for technology 2 because its power limit is 1100 W (MoR Techno 2 Max power curve is on 16.b). Technology 2 combined with its parameterization is unable to continue the mission;  at , the cycle begins a quick power increase phase. The comparison between MoI and technology 1 highlights a difference of more than 50%;  at , the mission is over. Only technology 1 has performed the mission.

The MoI is more pessimistic than the MoRs in the simulation results. In that way, model supplier and expert have understood the MoI because solutions are closer to technology and offer performances that are better than expected. However, each technology has advantages and drawbacks. Technology 2 is able to deliver more energy than technology 1, but technology 1 offers a faster power exchange.

Global model comparison

After each global model simulation, the power requested from the electric motor is calculated at the controller component model. This power depends on the mission profile and the global model parameterization. 17 shows a simulation result for a mission. The first graph is the comparison of the MoI and MoR of electric motor power consumed, and the graph at the bottom is the power distribution between electric motor and ICE, of interesting especially when ICE cannot furnish sufficient power for propulsion (i.e. strategy mode 2). In curves ion the Fig. 17.a, we see that the electric motor is solicited between T_1 and T_3, with two different step values of which separation occurs at T_2. With the MoI, requested power is lower than with MoR, which is by hypothesis the more reliable model. However, the difference is low small (around 150 W). Technically, the and its parameterization proposed by the supplier team is are close to the MoI: MoI modelling and simulation has supported the MoR building. In fine, the request package has successfully performed attained his its objective. From the system architect's point of view, the objective is to propose materials for the scenario. In that way, simulations performed by the model architect allow the identifying identification of how and when the electric motor is solicited. With curves in on the Fig. 17.b, the ICE is unable to furnish 3898 W between T_1 and〖 T〗_3, during for 0.7 h. In the scenario, the system architect wants to know the advantages of electrical propulsion chain addition before considering replacing or modifying the ICE. To estimate the architecture, mass balance is a material requested. In order to test the model, an optimization was done carried out with the minimization of a cost function composed of electric motor and battery masses and considering the mission success. A very first solution calculates an additional mass equals to 9.5 kg to the architecture (7.5 kg of Techno 1 battery and 2 kg for the electric motor). For a system architect, this kind of information supports his design decisions

CONCLUSION AND FUTURE CONSIDERATIONS

This paper addresses the common needs of software tool providers and industrial markets such as in the aerospace and automotive sectors. It also describes the methods that have been used to improve successful collaboration between industrial partners, and the challenging topics that still need to be explored in a multidisciplinary environment. Current inefficient ways of working create unnecessary iterations during the model integration phase, often responsible for increased product development lead time and cost, and schedule risk. To remedy this problem, the multidisciplinary models have to be understandable and easy to create. Thus it is necessary to maintain close links with the various disciplines and actors through clear information exchange.

Four major roles are identified: System Architect, Model Architect, Technology Provider and Domain Model Developer. This work also proposes a multi-view architectural method, aimed at reconciling the necessary high level and detailed design aspects with the help of the above actors. The integration of the two methodologies, MoI and MIC, narrows the knowledge gap between model designer and developer. The accuracy of the MIC, combined with the simulation capability of the MoI, represents a significant advantage. The freedom offered to the supplier is counterbalanced by the clear and direct model specification, in order to integrate it into a simulation chain. Misunderstandings are largely reduced, and a win-win collaboration is fostered. It is worthwhile considering an extension and refinement of the proposed method to support different specific domains of interest. The main long-term benefits of this work include significant reductions in time and in late inconsistency detection.

Fig. 3 .

 3 Fig. 3. Conceptual Design Stage Another industrial methodology called ARCADIA (ARChitecture Analysis & Design Integrated Approach) has been in operational use since 2008 in the Thales Company[START_REF] Roques | MBSE with the ARCADIA Method and the Capella Tool[END_REF]. ARCADIA is based on architecture-centric and model-driven engineering, and was supported by the use of "standard" language such as architecture Framework (e.g. NATO AF or NAF), and SysML/UML. However, ARCADIA promotes

Fig. 4 .

 4 Fig.4. Main Classes and Attributes

Fig. 6 .

 6 Fig. 6. Methodology to support simulation model building based on I&I and MoI -Dark boxes correspond to contributions

Fig. 7 .

 7 Fig. 7. Collaboration between Model Architect and Model Supplier: Information Flow 2

3

 3 Information Flow 1). By contrast, defined major roles of the Model Architect are designing a formal model architecture with a model-based systems engineering tool, specifying each sub-model with the Model Identity Card, and finally generating an executable MoI (see Fig. 3 Information Flow 2).

Fig. 8 .

 8 Fig. 8. Proposed Methodology

Fig. 9 .

 9 Fig.9. Hybrid parallel architecture

Fig. 10 .Fig. 11 .

 1011 Fig. 10. Formal Model Architecture Design

  After the reception of a model request package, each model supplier has developed a model called model of realization (MoR). The EM MoR is a synchronous permanent magnet motor model built around four equations and 11 parameters. All of these parameters concern the physical description of the motor (radius, pole number) or factors such as motor density or copper ratio. The battery MoR proposes a selection between two technologies (called Techno 1 and Techno 2). Each technology has its own characteristic values inside its model. The global model, which integrates these two models in place of the respective MoIs, is the simulation model. When we check the Modelica global model, 92 equations are present for the global model with MoI, and 112 for global model with MoRs.

Fig. 16 .

 16 Fig. 16. Battery MoI -MoR comparison Fig. 16 shows a local comparison between battery MoI and MoRs for battery masses equal to 80 kg. Fig. 16a is a battery discharge comparison between MoI and the two different technologies modeled with MoR. Fig. 16b shows in the full line curve the cycle used for this battery model test. The maximum power that technology 2 can deliver appears also to support the explanation for the top graph we propose in the next section.

Fig. 17 .

 17 Fig. 17. Global model MoI -MoR comparisonFig.17shows a simulation result for a mission. The first graph is the comparison of the MoI and MoR of electric motor power consumed, and the graph at the bottom is the power distribution between electric motor and ICE, of interesting especially when ICE cannot furnish sufficient power for propulsion (i.e. strategy mode 2). In curves ion the Fig.17.a, we see that the electric motor is solicited between T_1 and T_3, with two different step values of which separation occurs at T_2. With the MoI, requested power is lower than with MoR, which is by hypothesis the more reliable model. However, the difference is low small (around 150 W). Technically, the and its parameterization proposed by the supplier team is are close to the MoI: MoI modelling and simulation has supported the MoR building. In fine, the request package has successfully performed attained his its objective. From the system architect's point of view, the objective is to propose materials for the scenario. In that way, simulations performed by the model architect allow the identifying identification of how and when the electric motor is solicited. With curves in on the Fig.17.b, the ICE is unable to furnish 3898 W between T_1 and〖 T〗_3, during for 0.7 h. In the scenario, the system architect wants to know the advantages of electrical propulsion chain addition before considering replacing or modifying the ICE. To estimate the architecture, mass balance is a material requested. In order to test the model, an optimization was done carried out with the minimization of a cost function composed of electric motor and battery masses and considering the mission success. A very first solution calculates an additional mass equals to 9.5 kg to the architecture (7.5 kg of Techno 1 battery and 2 kg for the electric motor). For a system architect, this kind of information supports his design decisions

Table 2

 2 Battery model State of Charge (SoC) test

	(%)	MoI	MoR T1	MoR T2
		68.6	88.9	93
		25.6	73.6	83.2
		0 (empty)	63	out
		out	48.2	out

Table 2

 2

groups the battery behavior at four simulation times:

In order to precisely state our model request, a maximum power rate is introduced, with a time constant for discharge to calculate a max power: (6) With Equation ( 6), the B model can be refined with the additional equation: [START_REF] Herzig | A Conceptual Framework for Consistency Management in Model-Based Systems Engineering[END_REF] Finally, if , no more energy is available, and the mission stops (i.e. the simulation stops). The electric motor and battery MoIs are finished. All behaviors have been modeled with equations composed of factors that represent physical characteristics. The Values of these factors can be proposed as fixed, or with a max and/or min value in order to represent the design space given the supplier team (cf. Erreur ! Source du renvoi introuvable.). The final global model including electric motor and battery MoIs is visually similar to the model presented in Fig. 15, but with six new equations and three new parameters.


Christophe Cunat

Emmanuel Boutillon

Simplified Hardware Bit Correlator

come

Introduction

Binary correlator is a common tool in digital signal processing systems used for synchronisation in a binary stream. The principle is based on the detection of a known fixed pattern in a binary stream which can be corrupted by a noise with a probability of error p. If the degree of match between the N last received bits and the N bits of the training sequence seq(k) k∈{0,...,N -1} is above a given threshold, a new frame is detected. This principle is widely * Manuscript received January 24, 2007.

† Dr Cunat used to be with the LESTER Laboratory at the Université de Bretagne Sud and is now with TurboConcept. Pr Boutillon is with the LESTER Laboratory.

1 used in the context of symbol timing synchronisation for OFDM transmission [START_REF] Fort | A Performance and Complexity Comparison of Auto-correlation and Cross-correlation for OFDM Burst Synchronisation[END_REF][START_REF] Kulkarni | A High-speed 32-bit Parallel Correlator For Spread Spectrum Communication[END_REF][START_REF] Wang | FPGA Implementation of an OFDM-WLAN Synchronizer[END_REF].

In this letter, we propose a suboptimal algorithm which simplifies the bit-correlator hardware implementation in a FPGA. The probability of false alarm (P fa ) and the probability of nondetection (P nd ) for both optimal and the proposed bit correlator are given.

Bit correlation

The exact match score c e (n) for the n th bit between the training sequence seq(k) k∈{0,...,N -1} and the last N received bits of the sequence x(k) k∈N is defined in eq. ( 1) as the number of common bits.

c e (n) = N -1 k=0 seq(k) ⊕ x(n -k) (1)
Let's denote b k (n) = seq(k) ⊕ x(n -k) in the following discussion. If the bit rate is equal to the clock rate (i.e., a received bit at each clock cycle), the computation of c e (n) requires typically a shift register of size N to store the sequence x(k) k∈{n-N +1,...,n} [START_REF] Kulkarni | A High-speed 32-bit Parallel Correlator For Spread Spectrum Communication[END_REF]. Then, the b k (n) values can be directly computed from eq. ( 2).

b k (n) =        x(n -k) when seq(k) = 1, x(n -k) when seq(k) = 0. (2)
Finally, a pipelined addition tree performs the summation of the N partial results. The summation result is then c e (n).

For the sake of simplicity, the sequence length N is assumed to be a multiple of 4. In order to implement efficiently the bit correlation function described above onto a FPGA, the internal logic structure of the FPGA is taken into account. This structure consists of a set of 4-input/1-output Look-Up Tables (LUT) [START_REF]Virtex-II Platform FPGAs: Complete Data Sheet[END_REF][START_REF]Stratix II Device Handbook[END_REF]. This structure is found within FPGAs provided by the two companies representing about 90 % of the FPGA market [START_REF]Corporate Overview[END_REF]. To fully exploit the 4 inputs of a LUT, eq. ( 1) can be rewritten as in eq. ( 3)

c e (n) = N 4 -1 k=0 f k x(n -4k), x(n -4k -1), x(n -4k -2), x(n -4k -3) , (3)
with f k (i 0 , i 1 , i 2 , i 3 ) defined in eq. ( 4).

f k (i 0 , i 1 , i 2 , i 3 ) = 3 l=0 seq(4k + l) ⊕ i l . (4)
It can be noticed that each f k is the sum of 4 binary values. Thus, they take their value between 0 and 4; 3 bits (

f 2 k , f 1 k , f 0 k ) are required to code a value f k : f k = 4f 2 k + 2f 1 k + f 0 k . A direct implementation of f k can be done using 3 LUTs to generate the bit values f 2 k , f 1 k and f 0 k directly from (i 0 , i 1 , i 2 , i 3 ).
Let This partial score is also obtained for p e = 0.5. As p b and p e can be seen as equivalent, the probability of error will be denoted as p in the following.

The probability density function (p.d.f.) for the sum of 4 binary values is 4 }. In the system functional domain, when synchronised, p is significantly lower than 0.5, otherwise p is around 0.5. Thus, when synchronised, P (f k = 1) = 4p 3 (1 -p) can be considered as negligible compared to P (f k > 1) and it is not useful to discriminate the cases where f k is equal to 0 or 1. The function f ′ k expressed in eq. ( 5) is chosen for implementation.

P (f k = a) = 4 a p 4-a (1-p) a i.e. {p 4 , 4p 3 (1-p), 6p 2 (1-p) 2 , 4p(1-p) 3 , (1- p)
f ′ k (i 0 , i 1 , i 2 , i 3 ) = max (0, f k (i 0 , i 1 , i 2 , i 3 ) -1) . (5)
The new p.d.f. of

f ′ k is P (f ′ k = 0) = P (f k = 0) + P (f k = 1) and P (f ′ k = a) = P (f k = a + 1) for a = 1, 2, 3.
This function takes its value between 0 and 3: 2 bits f ′1 k and f ′0 k are needed to code the result. This function can be implemented using only 2 LUTs. This represents a significant lower complexity than the optimal solution. Note that the proposed approximated match score c a (n) takes its value between 0 and 3 4 N .

3 Theoretical performance for the proposed implementation

The performance can be evaluated theoretically according to the bit error probability p. In the case of the exact computation, the p.d.f. of c e is given by P (c e p = s) = N s p N -s (1 -p) s . In the case of the approximate function, the exact expression of the p.d.f. is complex to derive. Nevertheless, it is possible, for a given error probability p, to determine numerically its p.d.f. In fact, c a is the summation of N/4 random variable (r.v.). Thus its p.d.f. function is the convolution of the p.d.f of those r.v. In practice, the p.d.f. of c e is also obtained with the same method. Fig. 1 shows the p.d.f. for unsynchronised and synchronised input (with p = 0.3 and N = 64) for the exact and the approximated schemes. A detection threshold s t (p), an integer between 0 and N or 3 4 N , defines whether or not a detection occurs. From such a threshold, probability of false alarm P fa and probability of nondetection P nd are defined in eq. ( 6) and eq. ( 7), respectively. The receiver operating characteristic (R.O.C.) can be derived from these expressions: Fig. 2

P nd (p) = P (c p (n) ≤ s t (p)) = st(p) k=0 P (c p (n) = k) (6)
An optimal threshold is defined as expressed in [START_REF]IEEE Standard for Local and metropolitan area networks Part 16: Air Interface for Fixed Broadband Wireless Access Systems[END_REF]. It varies with p and is different for each computation scheme. Once again, Fig. 3 does not show significant differences between the two computational schemes.

s o t (p) = max st (P (c p (n) = s t ) ≤ P (c 0.5 (n) = s t )) (8)

5

Both the exact and approximated correlations have been implemented with a FPGA Xilinx Virtex2-2000 [START_REF]Virtex-II Platform FPGAs: Complete Data Sheet[END_REF]. For realistic implementation, the pseudorandom sequence is a Chu sequence [START_REF] Chu | Polyphase Codes With Good Periodic Correlation Properties[END_REF] using a single precision bit for quantification. This well-known sequence is a CAZAC (Constant Amplitude Zero AutoCorrelation) sequence like the ones used in [START_REF]IEEE Standard for Local and metropolitan area networks Part 16: Air Interface for Fixed Broadband Wireless Access Systems[END_REF]. Typically, over a multiple path channel [START_REF] Porat | Blind Equalization of Digital Communications using High-Order Moments[END_REF], with a detection threshold of SNR = 10 dB, p b is around 0.3 when synchronised and 0.5 when not synchronised. Over an additive white gaussian noise channel with the same detection threshold, p b is around 0.05 when synchronisation is achieved and 0.5 when not.

The exact correlation core of Xilinx (Bit Correlator from the CORE Generator tool [10]) is used as a state of the art design (denoted as Ref.).

A generic VHDL component implementing both exact and approximated correlator has been written: the final addition can be chosen as an optimized Carry-Save Adder (CSA) or a classical tree adder [START_REF] Cormen | Introduction to algorithms[END_REF]. Table 1 presents the place&route results (in term of logic (LUT), registers (DFF) and clock frequency) for the exact (reference, component with and without CSA) and approximated correlators (component with and without CSA). The targeted clock frequency is 280 MHz with no other specific timing contraint given.

The implementation of the approximated scheme shows about 15 % (resp.

30 %) of lower complexity in term of LUT (resp. DFF) compared to the reference design, associated with a larger clock frequency of about 30 %.

Conclusion

We have proposed a suboptimal binary correlator algorithm which simplifies FPGA implementation. The decrease of complexity (compared to a state 6 of the art design) is around 15 % in LUT count, 30 % in register count and a better clock frequency without any noticeable performance degradations.

Note that this decrease in complexity also involves a reduction of power consumption. Moreover, this method can easily be generalized. For example, if 5-input LUTs are available, the cases when f k equals 0, 1 and 2 can also be agregated. Finally, this method for aggregating least significant bits can also be efficiently applied by any ASIC designers.

  p e be the channel bit error probability and p b the probability that bit b k equals 0. When the received sequence x(k) is synchronised, the probability that bit b k equals 0 is p b = p e . Otherwise, p b equals 0.5. In fact, when not synchronised, at least P (P ∈ [1..N ]) bits of the last N received bits are random data not correlated with the training sequence. If P < N , N -P bits are non synchronized bits from the training sequence and the partial match score of these N -P bits is in average around N -P 2 (training sequences are generally chosen to have good auto-correlation properties).

  presents the R.O.C. drawn (with p = 0.35) for the two schemes. The two R.O.C. do not show any significant difference. The two curves are modified in the same manner for any variation of p. P fa (p) = P (c 0.5 (n) > s t (p)) = N k=st(p)+1 P (c 0.5 (n) = k)

Fig. 3

 3 Fig. 3 collects the probability P d of correct detection (P d = 1 -P nd ) and false alarm using s o t (p) as a function of p. The sequence length is N = 64.

Figure 1 :Figure 2 :

 12 Figure 1: Probability density functions for both exact and approximated computation schemes for N = 64. P.d.f are represented for a nonsynchronised input (p = 0.5) and a synchronised input with error probability p = 0.3. The thresholds defined in (8) are represented for the two schemes.

Figure 3 :

 3 Figure 3: Probability of synchronisation as a function of the probability of error on the input sequence (N = 64). Probabilities of correct detection (P d ) decrease as p increases and probabilities of false alarm (P fa ) increase with p.

Table 1 :

 1 Implementation results on a Xilinx Virtex2-2000 for logic (LUT), registers (DFF) and clock frequency after place&route (MHz)

				Exact		appr.
			Ref. Add. CSA Add. CSA
		LUT 439	659	508	376	377
	N = 256	DFF 810 1003 794	493	540
		MHz 219	214	272	231	281
		LUT 216	325	252	185	185
	N = 128	DFF 396	493	397	239	271
		MHz 219	210	281	253	281
		LUT 105	159	124	90	89
	N = 64	DFF 190	239	210	113	133
		MHz 280	265	281	285	285
		LUT	50	76	60	43	42
	N = 32	DFF	88	113	103	51	63
		MHz 286	280	283	283	287

Acknowledgment

This work has been supported by the Région Bretagne (PRIR n o 06003125 RITMO : Recherche et Intégration d'algorithme dans le domaine des Techniques multi antennes (MIMO)). Matlab code and VHDL code are freely available from the authors (http://web.univ-ubs.fr/lester/˜boutillon/correlator/correlator.html).


Andreas Makoto Hein

Marija Jankovic

Towards an Automatized Generation of Rule-Based systems for architecting eco-industrial parks

published or not. The documents may come   L'archive ouverte pluridisciplinaire

Introduction

An eco-industrial park is a set of companies within an industrial zone that share resources and thereby increase economic profitability and decrease environmental impact. One of the key underlying concepts of eco-industrial parks is "industrial symbiosis". An industrial symbiosis is the use of an underutilized resource from one actor, such as wastes, as a substitute for a new [Tapez ici] resource of another actor. The concept is therefore related to waste recycling. Fig. 1 shows an example of an industrial symbiosis from the eco-industrial park in Kalundborg, Denmark. Instead of using fresh water from a local lake, the coal power plant uses waste water from a close-by oil refinery. The coal power plant saves money, as fresh water is expensive and the oil refinery can save the capital cost for constructing a waste water treatment plant.

Fig. 1: Example of an industrial symbiosis at the eco-industrial park of Kalundborg [1]

An eco-industrial park is commonly based on a whole network of industrial symbioses. One of the challenges of creating industrial symbioses is that it is knowledge-intensive. For identifying symbiosis opportunities, companies need to share data in order to see if they can make use of another company's underutilized resources. However, companies usually do not share data if they do not see a benefit in sharing a priori. Without sharing data, it is difficult to find symbiosis opportunities.

For solving this problem, we previously developed a prototype of a rulebased system that captured some of the rules and heuristics for identifying symbiosis opportunities without the need of collecting proprietary company data and only using publicly available data. The system is intended to automatically identify promising industrial symbiosis opportunities and generate eco-industrial park architectures that may have a good economic and environmental performance. Similar rule-based systems for Earth observation satellite architectures have recently been developed and presented in [START_REF] Valero | Rule-based system architecting of Earth observation satellite systems[END_REF], [START_REF] Das | An Intelligent Spacecraft Configuration Tool for Mission Architecture Space Exploration[END_REF].

One of the drawbacks of such a static rule-based system is its maintenance and updating [START_REF] Li | Quality time-What's so bad about rule-based programming?[END_REF][5] [START_REF] Sollow | Assessing the Maintainability of XCQN-in-RIME: Coping with the Problems of a VERY Large Rule-Base[END_REF]. As new technologies and processes for implementing industrial symbioses are constantly developed, it is important to keep the rule-base up to date. Currently, this is done manually, which is time-consuming and expensive, as the information about the technologies and processes has to be "mined" via extensive literature surveys and expert interviews. However, recent developments in natural language processing (NLP) may have the potential to significantly improve the process of updating rulebases, underlying taxonomies, and ontologies.

In this paper, we first provide an overview of areas where NLP could add value to rule-based systems.

We start with a literature survey, covering the current state of the art in finding wasteresource pairs in industrial symbiosis and subsequently providing an overview of existing NLP and big data analytics approaches.

Problem formulation

The main objective of the rule-based matchmaking system, in the following called "symbiosis explorer", is to identify opportunities where wastes from one company can be used as a resource by another. These wastes would otherwise be discarded and the other company would instead consume fresh resources [START_REF] Deutz | Food for thought: Seeking the essence of industrial symbiosis[END_REF]. Such waste -resource transfers are called "industrial symbiosis" in the following, as defined by [START_REF] Deutz | Food for thought: Seeking the essence of industrial symbiosis[END_REF]. Industrial symbiosis is attractive in the context of sustainability as it promises to reduce environmental impact and is also feasible economically. However, there are several challenges associated with creating industrial symbioses. One of these challenges is the identification of potential symbiosis opportunities. Identifying these opportunities is not trivial, as there are several obstacles:

-Waste and resource stream data of companies are often confidential.

-Finding opportunities where wastes can substitute resources is not trivial, as it requires technical knowledge about the underlying processes. Furthermore, even when the composition of the waste

[Tapez ici]
and the resource is identical, there are cases where opportunities cannot easily be identified as they are named differently.

One of the shortcomings of existing matchmaking tools is that they require direct input from industrial companies, which presupposes that there is an initial motivation to share data. Another shortcoming is that existing matchmaking systems match wastes and resources based on term identity. It means that if one company creates "plastic" as a waste and another company needs "plastic" as a resource, a match is identified. However, if instead of "plastic" the company creates "plastic bottles", no match is identified. The e-Symbiosis project [START_REF] Cecelja | e-Symbiosis: technology-enabled support for Industrial Symbiosis targeting Small and Medium Enterprises and innovation[END_REF] aims at improving the current state of the art by adding waste and resource taxonomies and allowing for semantic matching. They use a taxonomic distance metric in order to quantify the likelihood that a waste can be matched with a resource.

In our research, we combined several approaches that were already introduced in the literature but are extending these approaches. We propose a system where no input from companies is needed for identifying symbiosis opportunities. Instead, we use so-called meta-models of industrial plants, where types of plants and their usual inputs and outputs are described. It allows for an a priori identification of symbiosis opportunities that can be later refined by more accurate data from the companies. Furthermore, as in the e-Symbiosis tool, we use taxonomies and a set of knowledge-based rules that describe when a certain waste can substitute for a resource.

Our proposal is to improve on this current system by introducing approaches to automatize the generation of rules in order to allow for an automated or at least semi-automated approach to creating matchmaking rules. Such a system would not only be interesting for the area of industrial symbiosis but for recycling markets in general. Fig. 2 shows the architecture of the proposed matchmaking system. From publicly accessible data bases such as books, patent databases, and Wikipedia, synonyms for wastes and resources are identified. In particular, we are interested in:

-Waste and resource compositions that are often introduced in online dictionaries and Wikipedia. -Identify synonymous terms, e.g. lime is equivalent to calcium oxide or calcium hydroxide.

Literature survey

Natural Language Processing (NLP) "employs computational techniques for the purpose of learning, understanding, and producing human language content." [START_REF] Hirschberg | Advances in natural language processing[END_REF] NLP is of interest for us, as finding synonyms and related terms in a corpus of literature is one of the problems for which NLP approaches exist.

In the following, we provide a quick overview of the NLP literature in order to identify approaches that are suitable for addressing our before-stated problem. [START_REF] Hirschberg | Advances in natural language processing[END_REF], [START_REF] Cambria | Jumping NLP curves: a review of natural language processing research[END_REF] provide overviews of current NLP approaches and outline possible future trends.

First approaches to NLP date back to the 1950s. First NLP approaches were mostly based on hand-coded rules for automated translation etc. Recent approaches rely on machine learning, mostly grounded in statistical inferencemaking using large bodies of annotated text. The statistical approaches seem to be better suited for capturing the highly contextual, fuzzy, ambiguous, and dynamic nature of natural languages.

[Tapez ici]

According to [START_REF] Hirschberg | Advances in natural language processing[END_REF] NLP can be defined as "the subfield of computer science concerned with using computational techniques to learn, understand, and produce human language content." An up-to-date overview of NLP approaches is presented in [START_REF] Hirschberg | Advances in natural language processing[END_REF], [START_REF] Cambria | Jumping NLP curves: a review of natural language processing research[END_REF].

The general problem we are dealing with is the automatic or semi-automatic identification of ontological (lexical) relationships. More specifically we are interested in identifying waste or resources that have different names but have the same meaning (synonyms), part-whole relationships (meronyms) for matching components of a waste or resource, and "is a" relationships (hyponyms) that can be used for building up taxonomies.

Methodologies for creating ontologies from text have been proposed such as in [START_REF] Maedche | Semi-automatic engineering of ontologies from text[END_REF]- [START_REF] Fortuna | Semi-automatic data-driven ontology construction system[END_REF]. An overview of algorithms for identifying synonyms from large bodies of text is shown in Table 1. Latent semantic analysis (LSA) is based on distributional similarity, which is based on the "distributional hypothesis" [START_REF] Harris | Distributional structure[END_REF]. The key idea of the distributional hypothesis is that words with similar meaning tend to appear in the similar contexts [START_REF] Firth | {A synopsis of linguistic theory, 1930-1955[END_REF]. However, LSA has shortcomings. As it uses a least-square fitting, it is based on the assumption that language data is normally distributed. Normal distribution is a precondition for least-square fitting. However, language data is not normally distributed [START_REF] Van De Cruys | Distributional Similarity -Overview and Applications[END_REF]. LSA is a purely statistic method. By contrast, Word2Vec is a machine learning approach, based on a 2-layered neural network [START_REF] Goldberg | word2vec explained: Deriving mikolov et al.'s negative-sampling word-embedding method[END_REF], [START_REF] Mikolov | Distributed representations of words and phrases and their compositionality[END_REF]. The neural network is trained on a text corpus to guess the words that appear in its context. Based on the distributional hypothesis, words with similar meaning tend to appear in similar contexts. Hence, Word2Vec can be used for comparing contextual words of different concepts. The more similar the contextual words, the more likely the concepts have the same meaning. As Word2Vec is based on a neural network, extensive training data is required. A third approach, called DFEAT, is based on supervised learning and distributional features [START_REF] Hagiwara | A supervised learning approach to automatic synonym identification based on distributional features[END_REF]. The value of the distributional feature indicates the commonality of the context of a word pair. Using a pattern-matching algorithm, the algorithm is trained with a test set of words. Compared to other synonym classifiers on the test set, the DFEAT algorithm showed a superior performance. Similar to finding synonyms, a number of algorithms have been proposed for identifying part-whole relationships. [START_REF] Ittoo | Extracting Meronymy Relationships from Domain-Specific, Textual Corporate Databases[END_REF] presents an approach for finding part-whole relationships in domain-specific data. Part-whole relationships in domain-specific data is more difficult to address than such relationships in general language, as the available data is much smaller. As a consequence, it is more difficult to train machine learning algorithms. The approach proposed in [START_REF] Ittoo | Extracting Meronymy Relationships from Domain-Specific, Textual Corporate Databases[END_REF] leverages on part-whole relationships extracted from an open-domain corpus and extends these relationships by domainspecific relationships. [START_REF] Berland | Finding parts in very large corpora[END_REF] is arguably the first automatic part extraction from a large, unlabeled, corpus with a reported precision of 0.55. The purpose of the method is to add the discovered part-whole relationships to an existing ontology or in a semantic lexicon. The algorithm rank-orders words that are candidates for parts of a whole, e.g. "speedometer" as part of a "car". [START_REF] Roberts | Learning meronyms from biomedical text[END_REF] presents an algorithm for identifying meronyms in biomedical text. They use the PartEx unsupervised learning algorithm that learns part-whole patterns from biomedical knowledge bases and infers part-whole relationships in yet unknown data. In its reported version it achieves a recall of 0.73 and a precision of 0.58. The author claims that no manual labelling of the corpus and manual selection of patterns is needed.

Regarding hyponyms, [START_REF] Hearst | Automatic acquisition of hyponyms from large text corpora[END_REF] presents an algorithm for identifying hyponyms in large corpora. [START_REF] Maedche | Ontology learning[END_REF] presents a semi-automatic approach for creating taxonomies from text on websites in the context of the semantic web. [START_REF] Kietz | A method for semi-automatic ontology acquisition from a corporate intranet[END_REF] presents a method for extracting ontologies from semi-structured information and text documents in domain-specific corporate intranets.

[Tapez ici]

Integrating these algorithms with other powerful NLP algorithms such as parsers has become easier due to the availability of several open source NLP tools such as GATE NLP, Stanford Core NLP Suite, Apache OpenNLP, and the Natural Language Toolkit. Furthermore, the availability of extensive material, resources, and waste taxonomies provide the data on which the algorithms can be run.

Proposed Research Approach

Based on the initial literature survey presented in the previous section, we propose a research approach for coming up with a matchmaking approach that is based on an automated or semi-automated data base of wasteresource substitution relationships. Fig. 3 depicts the steps of the research approach. First, a more extended literature survey on existing algorithms for finding synonyms, meronyms, and hyponyms is conducted. In case these algorithms are available in open source mode or can be rapidly implemented, they may be tested on small data sets for verifying their applicability to the matchmaking problem. The test results are compared and the most adequate algorithms in terms of applicability and efficiency selected. This subset of algorithms is then applied to a more realistic data set with wasteresource data. The resulting wasteresource pairs are then validated by experts. On the basis of the validation the algorithms precision with respect to the data set can be calculated.

Fig. 2 :

 2 Fig. 2: Architecture of the matchmaking system

Fig. 3 :

 3 Fig. 3: Research approach for finding and testing matchmaking algorithms

Table 1 : NLP algorithms for detecting synonyms

 1

	NLP approach	Input	Algorithm	Output	Key references
	Latent semantic anal-	Documents	Singular Value	Term set from doc-	[22], [23]
	ysis		Decomposition	ument with re-
				duced dimensional-
				ity
	Word2Vec	Candidate concept 2-layered neural	Ranked list of syno-	[24]
			network	nyms
	DFEAT	Training docu-	Supervised learn-	Ranked list of syno-	[21]
		ments and applica-	ing and distribu-	nyms
		tion documents	tional features

Conclusions

In this article we presented the matchmaking problem in industrial symbiosis. Identifying potential matches is difficult, as it is based on process-specific knowledge that certain wastes can be used for specific processes. However, capturing this knowledge in waste-resource matching rules manually is time-consuming. Therefore, we propose a NLP-based approach of semi-automatically extracting ontological relationships from domain-specific data sets that can be used as a basis for matching rules. We presented the results of an initial literature survey of algorithms that are able to find ontological relationships in large sets of unstructured text documents. Furthermore, we proposed a research approach for further extending the literature survey and to test the existing algorithms on small test cases and a realistic matchmaking case. For future work, additional problems that fall into the NLP category can be addressed such as semi-automatically identifying processes for converting wastes to resources.