T P Hue
email: ptbhue@fit.hcmus.edu.vn

D N Thuc
email: ndthuc@fit.hcmus.edu.vn

T D Thuy
email: dtbthuy@fit.hcmus.edu.vn

Isao Echizen
email: iechizen@nii.ac.jp

S Wohlgemuth
email: sven.wohlgemuth@me.com

A User Privacy Protection Technique for Executing SQL over Encrypted Data in Database Outsourcing Service

Keywords: Database outsourcing, database encryption, user privacy, access pattern privacy, access privacy. 1

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Amount of data held by organizations is increasing quickly and it often contains sensitive information. Management and protection of such data are expensive. An emerging solution to this problem introduces a new paradigm called database as a service (DAS), in which the database of an organization is stored at an external service provider. The advantages of DAS are cost savings and service benefits. There are three main entities in the DAS scenario (Fig. 1): (1) Data owner: individual or organization that is the subject of the data made available for controlled external use [START_REF] Hacigümüs | Executing SQL over encrypted data in the database-service-provider model[END_REF] User: individual or organization that requests data from the server (3) Server: organization that receives the data sent from the data owners and makes it available for distribution to users.

In DAS scenario, however, sensitive data, which is now stored on a site that is not under the direct control of the data owner, can be put at risk. Moreover, the data request of user can be revealed to the untrusted server to violate the privacy of the user. Therefore, the data confidentiality and user privacy need to be taken into account. To ensure data confidentiality, the data owner needs to hide the database's content before outsourcing it to the service provider. We also know that the privacy of a user is characterized by the query he poses to the server and its result. It is necessary to protect both the query and its result from the unauthorized parties (such as untrusted server) to protect the user privacy.

Encryption was often considered as a solution for data confidentiality ( [START_REF] Hacigümüs | Executing SQL over encrypted data in the database-service-provider model[END_REF], [START_REF] Agrawal | Order preserving encryption for numeric data[END_REF], [START_REF] Boyens | Using online services in untrusted environments -a privacy-preserving architecture[END_REF], [START_REF] Li | Authenticated Index Structures for Aggregation queries in Outsourced Databases[END_REF]). The order preserving encryption scheme supported the equality and range queries over the encrypted data [START_REF] Agrawal | Order preserving encryption for numeric data[END_REF]. Other work on privacy homomorphism illustrated techniques for performing arithmethic operations (+, -, x, /) on encrypted data ( [START_REF] Boyens | Using online services in untrusted environments -a privacy-preserving architecture[END_REF], [START_REF] Li | Authenticated Index Structures for Aggregation queries in Outsourced Databases[END_REF]). Hacigümüs et al. [START_REF] Hacigümüs | Executing SQL over encrypted data in the database-service-provider model[END_REF] proposed storing, together with the encrypted database, additional indexing information. By using the created index, the server could execute the queries over the encrypted data. There were four steps to process a query (Fig. 2): (1) the query Q posed by a user was translated by the query processor at the client site to its server-side representation Q S (2) Q S was sent to the server and was executed over the encrypted database (3) the result (in encrypted form) was sent to the client; it was decrypted and filtered out those tuples not satisfying the query condition (4) the final result was sent to the user by the client. All of the above-mentioned work revealed to the untrusted server the query type of users, which was the useful information for the server to predict the query being requested. Using these query execution techniques, the clients transfer to the server the same query patterns when the users pose the same query requests. The untrusted server may perform statistical attacks and exploit these query patterns. By correlating known public information with the frequent query patterns, together with the query types, the server can infer the users' trend of information, or more critical the users' trend of sensitive information, which violates the privacy of users [START_REF] Sion | Towards Secure Data Outsourcing[END_REF]. In this paper, we explore the techniques for executing SQL queries over the encrypted data without revealing to the server any information about the query or its result. Our proposal can defeat against the statistical attacks of the untrusted server compromising both data confidentiality and user privacy.

The remainder of this paper is organized as follows: section 2 presents the query execution solution for protecting the user privacy; section 3 presents the security analysis; section 4 is the experimental evaluation of our proposals; section 5 concludes the paper.

Our Proposed User Privacy Protection Technique

In this section, we propose a query execution technique which can protect the privacy of user. We adopt the database storage model and condition transformation technique proposed in [START_REF] Hacigümüs | Executing SQL over encrypted data in the database-service-provider model[END_REF].

Storage Model

For each relation r with the schema R(A 1 , A 2 , …, A n ), we store on the server an encrypted relation r S with the schema R S (t S , A 1 S , A 2 S , …, A n S ) where t S stores an encrypted string that corresponds to a tuple in relation r, each A i S is a corresponding index to the attribute A i that will be used for query processing at the server (Fig. 3). We can use any block cipher technique such as AES, RSA, Blowfish, etc., with the key size 128 bits. If there is unique user (also the data owner) in the system, we use one key for encrypting the whole database; otherwise, we use multiple keys which are managed by a key management mechanism [START_REF] Vimercati | Over-encryption: Management of Access Control Evolution on Outsourced Data[END_REF][START_REF] Atallah | Dynamic and efficient key management for access hierarchies[END_REF][START_REF] Hue | An Efficient Fine-grained Access Control Mechanism for Database Outsourcing Service[END_REF]. The index is created based on the mapping function Map R.Ai (v), which will be defined as the following:

• The partition function which partitions the attribute's domain of values into disjointed partitions: partition(r.A i ) = {p 1 , p 2 , .., p k }. • The identification function ident R.Ai (p j ) which assigns an identifier to each partition p j of attribute A i . • The mapping function which maps a value v in the domain of attribute A i to the identifier of the partition to which v belongs: Map R.Ai (v) = ident R.Ai (p j ), where p j is the partition that contains v. We use the operator D that maps the encrypted representation to its corresponding unencrypted representation. That is, D(r S ) = r. For differentiating the execution of an operation on the client site or on the server site, we denote the "S" in superscript form beside the operator with the suggestion to execute this operator on the server site. For example σ S denote the selection operator is executed (on the encrypted data) at the server site. We denote R + for the set of all the attribute of r: R + = {A 1 , …, A n }.

In our proposal, the principles of all the relational operators on each database management systems are unchanged. Besides the notation of the normal relational operators, such as ∏, σ, ⋈ , ∪, ∩, -, ← which stand for the projection, the selection, the join, the union, the intersection, the set difference, the assignment respectively as defined in [START_REF] Elmasri | Fundamentals of Database Systems, Fourth Edition[END_REF], we use the additional ones: τ denotes for the sorting operator, and γ denotes for the grouping and aggregation operator.

Condition Transformation

The condition mapping function, Map cond , translates a condition from a user's query to its corresponding one over the server-side representation [START_REF] Hacigümüs | Executing SQL over encrypted data in the database-service-provider model[END_REF]. This section we only refer to random mapping of two popular types of condition, which will be used in the next section. For the more consideration, please refer to [START_REF] Hacigümüs | Executing SQL over encrypted data in the database-service-provider model[END_REF]. We will use these two relations for illustrations:

CUST (CID, CNAME, CNID) MGR (MID, MNAME, MNID) Attribute = Value: Map cond (A i = v) ⇒ A i S = Map Ai (v). For example, Map cond (CID = 250) ⇒ CID S = 7. Attribute 1 = Attribute 2 : Map cond (A i = A j ) ⇒ ϕ ∨ (A i S = ident Ai (p k ) và A j S = ident Aj (p l )), where ϕ is p k ∈ partition (A i ), p l ∈ partition(A j ), p k ∩ p l ≠ ∅.

Solution for Protecting Access Pattern Privacy

Principles. Our solution was based on three principles: (1) all the relational operators (from the client query) are implemented by doing only the selection operator over the server-side database (2) we select (n + m) elements in each time of selection over the server-side database, where n and m are the parameters which determine the security level of our proposed system (3) minimizing the work done at the client side.

Conforming to the principle 1, the untrusted server cannot recognize the type of the query that is being requested. Respond to whatever the query type required by the user, the server simply does the selection. The algorithm Select_NTimes is used by the client for dispatching the selection request(s) to the server and receiving the result in encrypted form. The number of elements requested in each time depends on the total number of index values being requested and the values of n and m.

Principle 2 prevents the server from doing the statistical attacks to learn the frequent query pattern. In the case the users request the same query, the sets of elements the corresponding client request from the server in each time of selection are different with the high probability. The appropriate values of n and m should be suggested by the data owner or an expert in the field involved. We will analyze the 0 100 200 300 400

I = I -L End // card(I) > n Z = L ∪ N ) r ( σ 1 R S Z S A S ∈ ← ) 1 R ( σ 2 R L S A S ∈ ← 2 R R R ∪ ← End While Return R
The Select_NTimes algorithm operates in the following manner. Let T be the set of values of A S except the values in I. If the cardinality of the requested set I is less than n, the client adds to I the values in T in order to have a set Z having the cardinality (n+m) in each time of selection. In the case the cardinality of I is equal to n, the client conforms to principle 1 to add m values in T more. In the case the cardinality of I is greater than n but less than (n+m), the client to get randomly n values from I and add together with m ones getting randomly in T for each time of selection over r S . If the cardinality of I is greater than (n + m), the client flexibly selects (n +m) values randomly from I for each time of selection over r S . When receiving the result returned from the server, the client should remove the spurious tuples for saving the cost for decrypting them (see Fig. 4).

Fig. 4 Select_NTimes algorithm

We suggest decrypting the result one time after selecting from the server all the satisfied rows. By this way, we save the time of using resource of the client. However, it requires the client to store the result before decrypting all of them. An alternative way is to apply the client side operation to the tuples arriving over the answer stream as soon as they arrive without the need to store them.

We knew that sorting the input data is necessary for implementing operations such as join, union, intersection, duplicate elimination. Every tuple belonging to a single group of γ L will be in a single group of γ S L' computed by the server. The client only needs to consider tuples in a single group of γ S L' when computing the groups corresponding to γ L . The sort operator τ L on the tuples having been grouped by the server can also be implemented efficiently using the merge-sort algorithm. These are the reasons why we design the algorithm, named Select_NTimes_Grouped, which has the same function as Select_NTimes except that the result set is grouped according to the specified attributes after every selection done by the server. Algorithm Select_NTimes_Grouped(r(R), A, I, n, m, L) is used for selecting from encrypted relation r S (R S ) corresponding to the relation r(R) the tuple(s) having the value(s) at attribute A S belonging to the set of values I. The returned result is grouped by L S , the correspondence of L. By using Select_NTimes_Grouped algorithm, the operations that need the input data to be grouped or sorted (such as join, grouping and aggregation, sort, duplicate elimination) be implemented efficiently. Implementation of relational operators. Algorithm Selection (r(R),A,C,n,m We explain the above implementation using the example: σ CID = 500 (CUST). Map cond (CID = 500) ⇒ CID S ∈ {5}, which means I = {5}. Suppose that the parameters for attribute CID of relation CUST are n = 2 and m = 2, according to the algorithm Select_NTimes, because card(I) = 1 < n (n = 2), the client will choose (m+n -card (I)) = (2+2 -1) = 3 elements randomly from ident(CID) -I = {2, 7, 5, 1, 4} -{5} = {2, 7, 1, 4}. Suppose that 2, 1 and 4 are selected, which means N = {2, 1, 4}. The client requests the set L ∪ N = {5, 2, 1, 4} rather than requests only I = {5}. The client then decrypts the result and filters out the tuples satisfying the condition C.

• Selection operator

• Join operator

Algorithm Join (r(R), t(T), C, n, m)

For returning the result of r ⋈ C t, C is a θjoin condition I, J contain all possible partitions of A i , A j that exists at least one pair of them may provide some values of A i and A j that can satisfy the condition C: A i θ A j . result1 = Select_NTimes_Grouped(r(R), A i , I, n, m, A i ) result2 = Select_NTimes_Grouped(t(T), A j , J, n, m, A j ) result = σ C (D(result1 ⋈ For using our proposed JOIN algorithm, we identify that A i is CNID, A j is MNID, I = {2, 4, 3, 1}, J = {9, 8}. The client selects all the rows from the relation r S satisfying the condition 'CNID S in I', which resulted in result1. The client also selects all the rows from the relation t S satisfying the condition 'MNID S in J', which resulted in result2. The client executes the join operation between result1 and result2 with the join condition is Map cond (C), which resulted in result. The client continues executing the decryption operator on result and selecting the rows satisfying the condition C. Algorithm Projection (r(R),n,m,L) For returning the projection of r(R) on the projection attribute(s) L A ∈R + ; I = ident(A) result = Select_NTimes(r(R), A, I, n, m) return ∏ L (D(result))

• Projection operator

The projection operator cannot be implemented on the server because each tuple of r is encrypted together into a single string in the t S attribute of r S . After selecting all the rows of the relation r, the client decrypts the result and performs the projection. Algorithm Group_Aggregation(r(R),L,n,m) For returning the values of aggregation functions operating on each group L = L G ∪ L A, L G contains attributes on which the grouping is performed; L A corresponds to a set of aggregation operations.

• Grouping and aggregation operator

I = ident(A i ); A i ∈ L G result = Select_NTimes_Grouped(r(R), A i , I, n, m, L G ) return γ L (D(result))
The grouping and aggregation operation is denoted by γ L (r) where L = L G ∪ L A . L G is the list of attributes on which the grouping is performed while L A is the set of aggregation operations. The server does not perform any aggregation corresponding to L A . It returns all the rows of the relation r in responding to the client's request using Select_NTimes_Grouped algorithm. This result has been grouped by the server on the corresponding group of L G . The client decrypts this result and performs the grouping operation and computing the aggregation functions specified in L A .

• Sort operator Algorithm Sort (r(R), L, n, m) For sorting the tuples of r(R) by L I = ident(A i );

A i ∈ R + result = Select_NTimes_Grouped(r, A i , I, n, m, L) return τ L (D(result))
The sorting operator is implemented similarly to the grouping operator. The client firstly selects all the rows of the relation r using the Select_NTimes_Grouped algorithm. This result has been grouped by the server on the encrypted attributes of those in L. The client then decrypts the result, performs the sorting operation on the attributes in L. If the mapping functions of the attributes in R + are all orderpreserving, the grouping operation operated on each part of the result returned by the Select_NTimes_Grouped should be replaced by a corresponding sorting operation for saving the cost at the client. The reason is that the result returned by the server is presorted within the partition. Sorting the result is a simple local operation over a single partition.

The following three set operators must be executed on the two compatible relations. These operators are implemented by the same manner. They cannot be executed by the server because on the encrypted form of the relations r and t, it is impossible to tell whether or not a given tuple satisfies the current operator. The client firstly selects all the rows of two relations r and t using the Select_NTimes_Grouped algorithm, except the union operator (without duplicate elimination) using the Select_NTimes algorithm. The client then decrypts the results and performs the corresponding operation.

• Set operators Algorithm Difference (r(R), t(T), n, m) For returning the difference between r(R) and t(T) A ∈ R + ; B ∈ T + ; A and B have the same domain value I = ident(A); J = ident(B) result1 = Select_NTimes_Grouped(r(R), A, I, n, m, A) result2 = Select_NTimes_Grouped(t(T), B, J, n, m, B) return D(result1) -D(result2) Algorithm Algorithm Union (r(R), t(T), n, m) For returning the union of r(R) and t(T) A ∈ R + ; B ∈ T + ; A and B have the same domain value. I = ident(A); J = ident(B) result1 = Select_NTimes(r(R), A, I, n, m, A) result2 = Select_NTimes(t(T), B, J, n, m, B) return D(result1) ∪ D(result2) Algorithm Intersect (r(R), t(T), n, m) For returning the intersection between r(R) and t(R) A ∈ R + ; B ∈T + ; A and B have the same domain value. I = ident(A); J = ident(B) result1 = Select_NTimes_Grouped(r(R), A, I, n, m, A) result2 = Select_NTimes_Grouped(t(T), B, J, n, m, B) return D(result1) ∩ D(result2)

Security Analysis

Our proposed system use two parameters n and m. n is used for preventing the server from predicting the query type of the user based on the number of values to be requested. For example, when requesting an exact match query, the number of requested values is 1, which contrasts to the projection query with a larger number of requested values. m is used with the purpose of making noise to prevent the server from predicting the query type in the case the cardinality of the requested set is small (card(I) < n+m).

There is the trade-off between the security level and the communication and computation cost in our proposed system. The higher the value m is, the harder for the server to predict exactly the query is being executed. When the value of m is large enough, the probabilities of being selected of all the values in the considering domain are similar to each other, which creates difficulty for the server to predict the query type or the query pattern of users. However, the high value of m affects the performance of the system.

In the case the cardinality of I is greater than (m+n), each time of selection the client choose one set in N sets of values for selecting from server:

m + n ) I ( card C = N
. For preventing the case the server finding the intersection of the requested sets for predicting the query pattern, the value of N must be large enough. The higher the value of N, the more secure the system is. N becomes maximum if (n+m) approximates to card(I)/2.

Every attribute to which there may be have the query relates to should be set the values of n and m. For security reason, all the selection conditions done on an attribute should use the same values of n and m.

Experimental Evaluation

We present the experimental evaluation of our proposal. We implemented our proposed query execution method and the one suggested by Hacigümüs et al. [START_REF] Hacigümüs | Executing SQL over encrypted data in the database-service-provider model[END_REF], called Hacigümüs, and compared the query execution time between them.

By utilizing TPC-H benchmark [START_REF]Benchmark Specification[END_REF], we generated two relations containing information about customers and mangers: CUST (CID, CNAME, CNID) and MGR (MID, MNAME, MNID). These attributes mean customer's identity, customer's name and customer's nation identity. The attributes of MGR relation have the same meanings as ones in CUST. We generated 150000 rows for the relation CUST, with the CID ranged from 1 to 150000. We generated 1000 rows for the relation MGR. The nation identity attributes (CNID and MNID) ranged from 1 to 25.

Our experiments were carried out on an Intel © Core2 Duo Processor P8700 2.53GHz, 4GB RAM. Relevant software components are Windows 7 as the operating system, SQL Server 2005 as the database management system and Microsoft Visual Studio C++ 2008 as the programming language. We used the equi-width technique to partition the domain of attributes CID, CNID, MID and MIND. The domains of attributes CID and MID were partitioned into fragments, each fragment contained 49 integer values. The domain of attribute CNID was partitioned into 5 fragments while the domain of attribute MNID was partitioned into 3 fragments. We considered four queries: one exact match selection, one range selection, one join and one projection. Q1: SELECT * FROM CUST WHERE CID = 500; Q2: SELECT * FROM CUST WHERE CID >= 500; Q3: SELECT * FROM CUST, MGR WHERE CNID = MNID; Q4: SELECT CID, CNAME FROM CUST;

For the query Q1, the condition after mapping was CID S = 10. Firstly, we executed it 5 times using the execution process proposed by Hacigümüs et al. [START_REF] Hacigümüs | Executing SQL over encrypted data in the database-service-provider model[END_REF] and recorded the execution time. Secondly, by using our proposed access pattern privacy protection techniques, we executed Q1 with the value of n was 2 and the value of m run from 2 to 6, and computed the average execution time. We also repeated it 5 times. Thirdly, we did the same things with Q1 as the second execution time with the value of m was 3 and n run from 2 to 6. For each pair of n and m, we run the query 10 times with different random sets of selection values according to the Select_NTimes algorithm. Fig. 5 (a) demonstrates that there is the small difference between the execution time of the two latter running times. The amount of execution time of these two running times is certainly higher than that of Hacigümüs et al. because the higher number of selection values were selected from the server. For the query Q2, the condition after mapping was the set containing 290 values. We executed Q2 using Select_NTimes algorithm with the cardinality of the selection sets of values in each time of execution the selection (that was m+n) varied by 50, 60, 70, 80, 90. For each value of (m+n), we run the query 10 times with different random sets of selection values. Fig. 5 (b) demonstrates that the execution time when using our proposed execution technique is the same as that when using Hacigümüs' one. The differences in the execution time between the values of (m+n) are low during 10 times of running the experiment.

Executing Q3 by using Select_NTimes_Grouped algorithm (with n= 2 and m = 3) costs the same amount of time as that by using Hacigümüs' one, Fig. 5 (c). The result of the join operator contains 599988 rows which need more than 8 minutes to produce.

The result of the query Q4 contains all the rows of the CUST relation (150000 rows). We executed Q4 using Select_NTimes algorithm with the cardinality of the selection sets of values in each time of execution the selection (that was m+n) varied by 20, 50, 60, 70, 80. For each value of (m+n), we also run the query 10 times with different random sets of selection values. What we see on the Fig. 5 (d) is that the differences in execution time between the values of (m+n) are small, and the execution time of our proposed techniques is the same as that of Hacigümüs' one.

Conclusion

In this paper, we analyze the existing solutions for protecting data confidentiality and user privacy in DAS. The recent and well-known proposal of Hacigümüs el al. [START_REF] Hacigümüs | Executing SQL over encrypted data in the database-service-provider model[END_REF] is expressive but cannot defeat against the statistical attacks of the untrusted server, which may violate the data confidentiality and the user privacy. We propose the simple but robust technique for executing the relational operators over the encrypted database which can protect both the data confidentiality and the user privacy. Experimental evaluation demonstrates that our proposal less affects the system's performance and is applicable in the real world.

Fig. 1 .Fig. 2 .

 12 Fig. 1. Diagram of DAS

Fig. 3

 3 Fig.3Data storage model[START_REF] Hacigümüs | Executing SQL over encrypted data in the database-service-provider model[END_REF]

For example,

  Map cond (CUST.CNID = MGR.MNID) ⇒ (CUST S .CNID S = 2 ∧ MGR S .MNID S = 9) ∨ (CUST S .CNID S = 4 ∧ MGR S .MNID S = 9) ∨ (CUST S .CNID S = 3 ∧ MGR S .MNID S = 8) ∨ (CUST S .CNID S = 1 ∧ MGR S .MNID S = 8).

  proposed techniques in section 3. Principle 3 keeps the spirit of database outsourcing service in which most of work should be done by the server. Solution for Selecting Data from the Server. All the relational operations over the encrypted database will be implemented by using the Select_NTimes algorithm. Note that GetRand(n, I) is the function for getting randomly n elements from the set I while card(I) is the function for returning the cardinality of the set I.Algorithm Select_NTimes(r(R),A, I, n, m) For selecting from the encrypted relation r S (R S ) of relation r(R) the tuples with the value at the attribute A S belonging to the set of values I, I ⊆ Ident(R.A) T = ident(r.A) -I; R = ∅ While card(I) > 0 Begin N = ∅ If card(I) <= n then Begin L = I If card(I) < n then N = GetRand(m + n -card(I), T) Else if card(I) = n then N = GetRand(m, T) I = ∅ End Else // card(I) > n Begin If card(I) <= n+m then Begin L = GetRand(n, I); N = GetRand(m, T) End Else // card(I) > n+m L = GetRand(n+m, I)

)

  For selecting from relation r(R) the tuple(s) having the value(s) at attribute A satisfying condition C Map cond (C) ⇒ A S ∈ I; result ← Select_NTimes(r(R), A, I, n, m) return σ C (D(result))

  For instance, with the join condition C: CUST.CNID = MGR.MNID, Map cond (CUST.CNID = MGR.MNID) ⇒ (CUST S .CNID S = 2 ∧ MGR S .MNID S = 9) ∨ (CUST S .CNID S = 4 ∧ MGR S .MNID S = 9) ∨ (CUST S .CNID S = 3 ∧ MGR S .MNID S = 8) ∨ (CUST S .CNID S = 1 ∧ MGR S .MNID S = 8)

Fig. 5 .

 5 Fig. 5. Execution time when using our access pattern protecting solution comparing with that when using techniques of Hacigümüs el al.: (a) Q1 (b) Q2 (c) Q3 (d) Q4


Arne Schramm

Bernhard Wolf

Raik Hartung

André Preussner

André Preußner

Real-Time Production Monitoring in Large Heterogeneous Environments

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Modern production facilities are being controlled and monitored by an IT back end consisting of various systems such as Enterprise Resource Planning (ERP), Manufacturing Execution Systems (MES), Supervisory Control and Data Acquisition (SCADA), and numerous analysis and decision support systems. The constant monitoring of production assets helps companies to save costs, predict downtimes, prevent the production of scrap, and dynamically adjust production processes. State-of-the-art production machinery often is equipped with numerous sensors, such as vibration, power or temperature sensors, giving information on the health and production state of the machine. In their effort to also optimize older equipments, manufacturers apply new sensors to existing machines to get more insight.

While more and more data is collected at the shop floor, analyzing this data has become a serious challenge. For instance, a mid size semi-conductor equipment can create up to 40.000 data values per second. Having an entire production line consisting of 500 to 1000 machines can easily generate more than one terabyte of data per day. This amount of data brings a number of challenges. The mere gathering of the data in a back end system can already be a problem for any network, given that it might not be used exclusively for this purpose. Analyzing this data in real-time is another non-trivial task that needs to be done in order to react in time to any event on the shop floor. In addition to scheduled analysis jobs like the extraction and continuous refinement of patterns found in historic data, system engineers need to query historical and real-time production data ad-hoc, to fully understand the systems in their responsibility, to react in time, and to find possibilities for improvements.

We present a hybrid system combining distributed complex event processing (CEP) [START_REF] Luckham | The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems[END_REF] and in-memory database technologies to collect and analyze large amounts of data in typical heterogeneous production environments in real-time. The system enables users to dynamically query streams of data and subscribe to results. The combination of both technologies allows users to analyze live and historical data in real-time. Furthermore, analyses can be adapted dynamically to explore the behavior of the production system instantly.

Related Work

In our work we combine knowledge from two domains: stream processing and business intelligence (BI). Stream processing and CEP mechanisms are used for processing production data in real-time. The results can be analyzed like in typical BI scenarios using data warehouse applications. In this section earlier work from both areas is discussed.

Originally, the purpose of data warehouses (DW) was to support strategic decisions [START_REF] König | Erfolgsfaktoren in Business Intelligence Projekten[END_REF]. With the increasing dynamics of markets the demand for tactical or even operational decision support emerged and approaches for "active data warehousing" [START_REF] Polyzotis | Supporting Streaming Updates in an Active Data Warehouse[END_REF] were introduced. In [2] different scenarios for real-time data warehousing are discussed. An architecture is described which processes events in real-time and instantly stores the results to the DW. Analyses are executed based on the persisted DW data automatically or on a user's request, i.e., representing a snapshot at this time. However, updating the data in DW does not automatically update the results of analyses.

Over the last decade several stream processing and CEP systems were proposed and commercialized [START_REF] Cugola | Processing Flows of Information: From Data Stream to Complex Event Processing[END_REF]. These systems enable real-time processing directly in the main memory of the system. Queries are continuously executed on the streaming data providing results updated in real-time. To increase performance and fault tolerance distributed stream processing systems were developed, that allow for early data processing close to the data sources. The disadvantages compared to a DW are that data in the main memory are volatile and limited to the much smaller size of the main memory (gigabytes vs. terabytes).

To leverage the advantages of both data processing paradigms, hybrid systems , such as the federated stream processing architecture MaxStream [START_REF] Botan | Federated Stream Processing Support for Real-Time Business Intelligence Applications[END_REF], were introduced. MaxStream extends the SAP MaxDB Database Federation Engine with data agents, that act as an access point to stream processing engines. Two new operations to support stream queries were implemented: Streaming Input and Monitoring Select. The first enables the system to pass data streams to the federator and to persist them. The latter returns results once as soon as new data sets are found in the output table. The benefit of this system is the possibility to deploy distributed queries over stream processing engines and databases. Thus, historical and current data can be considered in one query. Since contin-uous queries are not supported, results have to be polled from the federator by using the monitoring select statement, which is a major drawback for real-time processing.

The Hybrid Monitoring System

The systems architecture consists of four layers (Figure 1). Those layers are clearly separated by concerns. Starting from the data sources (shop floor) to the data sinks (users or systems) we defined the following layers: The Data Integration layer guarantees the seamless integration of shop floor data from arbitrary source systems into our solution. Its main tasks and components are described in Section 3.1.

The Data Processor layer receives and processes real-time as well as historical data. Results are continuously forwarded to the next layer. A detailed description of the layer is given in Section 3.2.

The Data Broker layer acts as a single point of entry to the system for various data consumers. It takes care of distributing processing results, handling subscriptions and providing system information. Section 3.3 depicts details of this layer.

All data of the system (raw data, processed data and metadata) can be accessed in the Data Consumption layer. Section 3.4 gives insight in tasks and requirements of this layer.

The management of the systems components as well as the provisioning of metadata is handled by a Management component (Section 3.5) spanning multiple layers.

Data Integration

Due to the fact that shop floor infrastructure is already defined in most application scenarios, our architecture needs to be integrated into it. This means it needs to connect to various systems, equipments and sensors that can have standardized or proprietary protocols and data format definitions. Data from the shop floor is sent to the Data Processor layer via the data input interface. Therefore, the Data Integration layer has to provide the following functionality:

connectivity to sensors and systems, protocol and data transformation, and unified, push based data transfer to the Data Processor layer.

Since integration always needs to be tailored to the specific environment; there cannot be a generic solution to that. However, a common approach to minimize integration effort is the usage of standardized integration middleware. The integration solution in our architecture needs to fulfill the requirements listed above and support a distributed collection of all data. As stated in the introduction a single equipment can already produce thousands of values per second. Collecting all raw data of a whole production site centrally is not feasible. Therefore data has to be collected and integrated by a distributed integration solution.

Data Processor

The Data Processor layer contains the components needed to:

query real-time data (e.g., calculate live performance indicators (PI)), query historical data (e.g., retrieve reference data), combine real-time and historical data (e.g., compare live and historical data), persist query results (e.g., for further reference), and manage running queries (create, deploy, start, stop, undeploy).

The Data Integration layer pushes all shop floor data to the CEP component in the Data Processor layer. There it can be processed, persisted, and forwarded to the next layer. The processing of data is done by CEP queries. These queries define logic that is executed on all or only selected data arriving. A typical CEP query could, e.g., collect all power consumption data of a machine for a given time and continuously calculate the moving average on it1 . The results of queries can be input for further queries, persisted in the Database or forwarded to the Stream Broker (Section 3.3) for distribution.

Streams can also be persisted in the Database using the Stream To Database Converter. Previously persisted raw data or query results can be used for complex analyses like pattern detection or for combination with real-time data. The persisted data of a machine could, e.g., be used as a reference for the machine's currently collected data to detect changes in the machine behavior and predict failures or problems. To retrieve data from the Database, the Database To Stream Converter creates streams from database tables and passes them to the CEP Engine component.

The Query Manager component handles multiple CEP nodes which are located close to the integration nodes in the network. The management of these nodes comprises the starting and stopping of nodes as well as the deployment and distribution of queries.

Data Broker

The purpose of this layer is to provide a single point of access for data consumers. It consists basically of two components -the Stream Broker and the Consumption Manager. While the Stream Broker has the typical tasks of a broker in a Message-Oriented-Middleware (MOM) like JMS [START_REF]Java Message Service Specification -Version 1[END_REF] or WS-Notification [START_REF] Graham | Web Services Notification (WS-Notification) -Version 1[END_REF], the Consumption Manager provides the interface to the upper layer. By using the Consumption Manager, consumers can read all relevant data of the system, run queries and subscribe to results.

The benefit of this separation is increased scalability: Classical MOM approaches like JMS lack scalability because of the centralized broker. This limits the maximum number of messages the system can handle in a certain time frame. In our approach, this problem is solved by running multiple stream broker instances. Moreover, this is completely transparent for consumers, since they are only communicating with the Consumption Manager. The Consumption Manager stores, which result streams are registered at which broker instance, and forwards subscriptions accordingly.

Data Consumption

The Data Consumption layer at the top level groups all potential data consumers. A Consumer component can be a graphical dashboard or other IT systems like ERP, MES or SCADA. Dashboards can support engineers in various tasks such as monitoring production equipment or exploring the system and finding possibilities for improvements. IT systems can subscribe to streams to adapt production processes or trigger actions based on events in the shop floor.

Any Consumer in our architecture implements the Data Input interface to receive (processed) stream data from the Stream Broker. To retrieve metadata, to send subscriptions, and to deploy new queries, the Consumer uses the Consumption interface implemented by the Consumption Manager in the Data Broker layer.

Management

The Management component spans the Data Processor layer and the Data Broker layer. It contains two sub-components -the Registry and the Repository.

The Registry component is used by all other components for service discovery inside the system. Every component registers itself at the Registry when started. Other components can then find the registered components via the Registry, so that the system does not need to be configured manually when starting components on different nodes in the network. The Repository contains all metadata describing the system and the data available in it. We distinguish between physical metadata and logical metadata.

Physical Metadata Repository (PMR): The PMR provides data helping the user understanding the real-world system landscape and mapping it to data in the streaming system. It also contains data needed by the Query Manager and Consumption Manager to manage queries in the system. The PMR holds a hierarchy of physical components which is used to model the real-world environment. A physical component is meant to be any kind of shop floor device, e.g., a sensor. The hierarchy of physical components represents the structure at the shop floor. Logical Metadata Repository (LMR): The LMR contains information about streams and queries available in the system. A simplified structure of the LMR meta-model is depicted in Figure 2. The central entity is the stream. A stream can have different sources: it can either be produced from a database table, it can be retrieved directly from a physical component, be the result of a query, or a combination of these. A stream is an instance of a defined stream type. This classification allows to check, whether a stream can be processed in a certain query or not. We envision a query as the combination of a query template with concrete input streams and parameters. A query template defines the logic of a query that can be applied to streams of a certain stream type. The concept of streams, stream types, queries, and query templates allows the definition of complex logic by an expert, which can then be re-used by consumers of the system to analyze actual data from concrete streams.

Implementation

The concepts were implemented using SAP's CEP and in-memory solutions. However, other CEP or in-memory systems can be integrated in a simple way by utilizing the defined interfaces. The implementation is currently running in a real production facility processing PIs [START_REF] Hesse | Reference model concept for structuring and representing performance indicators in manufacturing[END_REF] in real-time.

A performance analysis showed the real-time capabilities of our system. For that, we distinguish between two message types: control and data messages. Control messages are used to manage the system and are not critical w.r.t. performance. In our architecture control messages are sent via web services usually taking less than 300ms. In contrast, data messages contain real-time stream data and are sent directly via UDP. The overall performance depends on the CEP, the Stream Broker, the networks bandwidth and the message size. With a typical message size of 250 Byte the Stream Broker can send and receive up to 40000 messages per second in a 100 MBit network. In a 1 GBit network the value increases to 90000 messages per second with a latency of 0.6 ms.

The results do not include a CEP. The performance of the CEP depends on the specific implementation and the complexity of the queries. There are currently no standardized CEP benchmarks, however, a first impression of the performance can be found in [START_REF]Evaluating Sybase CEP Performance[END_REF]. Compared to the broker's performance the throughput is similar, thus, a slowdown of the system is not expected.

Conclusions

A main challenge of today's production environments is real-time analysis of large volumes of data collected at the shop floor. The heterogeneous IT infrastructure, changing requirements and different standards are additional issues to be solved in order to achieve an end-to-end data integration.

In this paper we presented an approach for real-time production monitoring in large, heterogeneous environments. Our solution combines emerging data processing technologies, i.e., a distributed CEP system with in-memory databases. By this combination, we compensate the limitations of the CEP system in terms of available memory, and further integrate persisted data without having the update latency of a database. To further increase the performance of the data processing, stream brokers are utilized to separate the data processing from result distribution.

The application of this hybrid system to the manufacturing domain enables us to continuously (pre-)process data of the shop floor assets in real-time and close to its source. Consequently, network load is reduced whereas scalability is increased. Our system allows to create and deploy new queries dynamically so that running analyses can be adapted to changed requirements.

Fig. 1 .

 1 Fig. 1. Architecture Overview

Fig. 2 .

 2 Fig. 2. Simplified Repository Structure

Details of a reference model for performance indicators developed in the KAP project are described in[START_REF] Hesse | Reference model concept for structuring and representing performance indicators in manufacturing[END_REF].

Acknowledgements

The paper presents results of the KAP project (260111), which is co-funded by the European Union under the Information and Communication Technologies (ICT) theme of the 7th Framework Programme for R&D (FP7).


Christos Alexakos
email: alexakos@ceid.upatras.gr

Manos Georgoudakis

Athanasios P Kalogeras
email: kalogeras@isi.gr

Spiridon L Likothanassis

Ontology-Based Flexible Multi Agent Systems Design and Deployment for Vertical Enterprise Integration

Keywords: ontologies, multi agent systems, vertical enterprise integration

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The need to increase the competitiveness of enterprises, especially in the manufacturing sector, is profound. Intra-enterprise interoperability is a prerequisite to this end, making possible the vertical integration of systems / applications residing at different levels of the classical manufacturing environment hierarchy. This need is especially felt when modern enterprises have to support such advanced business models as mass customization that require a robust enough environment that may react effectively and adapt to unexpected events and uncertain timing. Distributing intelligence and providing autonomy to different levels in the manufacturing environment hierarchy may positively contribute to this end. MAS along with a model representation of the enterprise environment and the relevant semantics are fundamentals for such an approach.

The proposed framework is based on the concept of simple definition of the functionalities of an integration MAS that permits system semi-automatic implementation and deployment, with the following challenges:

• The description of MAS modules, their functionalities, processes and data exchange protocols must follow a human understandable way. Model-based design using UML is a good paradigm for design of systems behavior by engineers. • The implementation phase of MAS must include the least possible code implementation, accelerating the deployment procedure and enforcing system re-usability. The use of modular system architecture, where the modules can be easily devel-oped and re-used, in combination with code-generation of system main components can significantly decrease the need for code programming.

• System definition must be computer-understandable, allowing computer software to read MAS description and proceed to the appropriate actions, such as code generation, agent creation and data mapping. XML and RDF are open standards that can easily define concepts, be delivered to systems and parsed by them. • The information integration between heterogeneous systems is a major issue in enterprise system integration; without the "common understanding" of the data exchanged between systems the orchestration of the business processes is meaningless.

In order to face the aforementioned challenges, the proposed framework is accompanied by a concrete methodology for MAS definition, implementation and deployment phases based on GAIA [START_REF] Zambonelli | Developing Multiagent Systems: The Gaia Methodology[END_REF] agent-oriented software engineering (AOSE) methodology. Furthermore, a set of tools support the three phases of the methodology establishing an integrated architecture for the framework.

The rest of the paper is organized as follows: In section 2 a brief presentation of the related works on ontology-driven design and deployment of MAS is provided. Section 3 presents the proposed framework methodology and its main components along with its supporting tools. Finally, some conclusion is given in chapter 4.

Related Work

MAS model development is supported by a number of AOSE methodologies and technologies [START_REF] Akbari | A survey of agent-oriented software engineering paradigm: Towards its industrial acceptance[END_REF], characterized by different levels of maturity. GAIA methodology is very popular [START_REF] Leitão | Recent Developments and Future Trends of Industrial Agents[END_REF] because it provides a strong design tool for engineers in order to describe the functionalities of a MAS along with the behavior of the agents acting in it. According to the GAIA-approach the behavior and interaction of an agent-based system is described by a set of roles with role related activities and a set of interactions among the roles. GAIA is used in various approaches for MAS design in enterprise / manufacturing integration [START_REF] Girardi | A knowledge-based tool for multi-agent domain engineering[END_REF].

During the recent years ontologies have been used as tools in model -driven architectures for defining the detailed functionality of a MAS. The semantic basis is the frame-based ontology ONTODM. ONTOMADEM [START_REF] Bratukhin | Functional Analysis of Manufacturing Execution System Distribution[END_REF] is a knowledge-based tool for designing MAS based on the MADEM MAS design methodology. ONTOMADEM is using a frame-based ontology constructed with Protégé tool. Bittencourt et al. [START_REF] Bittencourt | Modeling JADE Agents from GAIA Methodology under the Perspective of Semantic Web[END_REF] propose an ontological model for defining MAS functionalities and components driven for two ontologies, one describing GAIA methodology agents and one describing JADE agent implementation. The model uses SWRL rules for mapping GAIA agent roles and activities to JADE agents and behaviors. Nevertheless, a common denominator in most of these approaches is the lack of automatic creation of MAS.

In the runtime phase of MAS, ontologies in most approaches are used for supporting semantics common understanding of the integrated data exchanged between agents. Few proposals elaborate ontologies from the MAS design phase to deployment. O-PRS (Ontology driven Procedural Reasoning System like model) [START_REF] Mousavi | An Ontology Driven, Procedural Reasoning System-Like Agent Model, For Multi-Agent Based Mobile Workforce Brokering System[END_REF] utilizes OWL ontologies to express the concepts in Believe, Desire, Intention (BDI) agent architecture. The ontologies add the appropriate semantics to the exchanged messages in order for the agents to understand how to act. Nyulas et al. [START_REF] Nyulas | An Ontology-Driven Framework for Deploying JADE Agent Systems[END_REF] proposed an ontology-driven framework for design and deployment of MAS on top of Java Agent DEvelopment Framework (JADE) framework (http://jade.tilab.com/). The framework is based on the definition of MAS functionality using three Ontology Web Language (OWL) ontologies (Data Source, Task-Method and Deployment). For MAS deployment, special purpose agents (Controller Agent and Configurator Agent) are used in order to create and monitor task agents according to the semantic configuration.

3

Proposed Integration Framework

Design to deployment methodology

The proposed methodology covers the three phases of system engineering: design, implementation and deployment. For simplicity, the testing phase is considered as part of the implementation phase. Figure 1 depicts the major and optional steps of the methodology in the three phases.

Fig. 1. Design to Deployment Methodology

The core aspect of the proposed methodology is the MAS semantic definition in terms of ontologies. Ontologies represent powerful tools for defining the knowledge of a domain. In the case of enterprise system integration knowledge includes the business processes, the exchanged information and business logic executed from the participating systems. Ontologies describe the concepts in terms of axioms that for the shake of simplicity can be considered as sentences such as "Agent A executes the Invoice Procedure". In modern ontology languages like OWL, a more object oriented approach is used where entities follow a hierarchical structure enforced by relationships between them. OWL is an ontology language generated on the concept of Semantic Web, thus its main representation format is based on XML and RDF, permitting both human and computer understandability. For this reason, it is used as the basis for MAS definition in the proposed framework.

OWL Ontologies follow the T-Box and A-Box distinction which is drawn in Description Logics. OWL ontologies are composed of two functional parts, the first part is the ontology scheme (T-Box) and the second is a set of instances of the ontology scheme containing the data related to the described domain (A-Box). The proposed methodology uses as core ontology scheme the OWL-GMO (Gaia MAS Ontology) ontology that defines the core entities of MAS system following the widely accepted GAIA design methodology. Each agent role is depicted as an instance of OWL-GMO. Furthermore, OWL-GMO provides entities and relations for the definition of agent behaviors and messages exchanged. Other pre-existing ontologies or newly-composed ones can be integrated in the core ontology scheme in order to define the information semantics of the data used by the participating systems and agents.

The implementation phase includes the code generation of the components defined by OWL-GMO followed by the packaging of external modules that execute specific business logic functionalities. Agents and their functionalities (behaviors and message exchanged) are implemented following the specification of agent implementation of JADE. JADE supports the implementation of distributed software agent systems where software agents are running in different hosts. Moreover, the agent instances are managed according to globally accepted FIPA specifications. Finally, JADE agents follow Agent Communication Language (ACL), a well-structured schema for message exchange.

The specific business logic or functionalities that have to be executed by the agents must be implemented as modules providing specific APIs for invocation by the core agent implementation. In this case, the binaries or java code of these modules will be included in the core generated code. Finally, the code will be compiled and ready for deployment to the real enterprise environment.

Architecture components

Each distinct step of the aforementioned methodology is supported by software tools either providing graphical user interface to the users or automatically executing tasks. Figure 2 • Packaging Manager is responsible for managing the generated code and the imported modules and creating the final application package for compilation. • Binary Builder is the tool that builds the final MAS system. Binary Builder can be directly connected to the deployment or testing environment in order to automatically deploy the binary code.

Fig. 2. Framework Methodology Software Realization Architectural Components

OWL-GMO

As aforementioned, OWL-GMO is the core ontology of the proposed framework used to define the agents and their behavior in MAS. OWL-GMO entities come from the terms defined in the GAIA methodology. The ontology is based on two superclasses:

• AgentSystemEntity which abstractly defines the entities used by GAIA methodology to define a MAS. • AbstractConcept which defines supporting entities used to define concepts of the behavior and functionality of the MAS (data, processes, APIs, etc).

According to GAIA, each agent system comprises a set of agent roles. Each role is defined by four attributes: responsibilities, permissions, activities, and protocols. Responsibilities determine functionality and, as such, are perhaps the key attributes associated with a role. Responsibilities are divided into two types: liveliness properties and safety properties. In order to realize responsibilities, a role has a set of permissions. Permissions are the rights associated with a role. Therefore, the permissions of a role identify the resources that are available for that role in order to realize its responsibilities. In the kind of system that has been typically modeled in this work, permissions tend to be information resources. Activities are actions associated with the role and are carried out by the agent without interacting with other agents. Finally, a role is also identified with a number of protocols which define the way that it can interact with other roles. Each protocol is defined by its initiator role, the responder roles, input data, output data and the process executed.

Figure 3 depicts the OWL-GMO visualization. The classes AgentRole, RoleResponsibility, RolePermission, RoleProtocol and RoleActivity are the subclasses of the class AgentSystemEntity and define the main entities of GAIA methodology. For RoleResponsibility there are two subclasses, LivenessProperty and SafetyProperty following GAIA specifications. These classes following by relationships expressing specific concepts and restrictions (i.e. AgentRole accessResourcesAccordingTo RolePermission) are used for the definition of the MAS.

Fig. 3. OWL-GMO Ontology

Furthermore, OWL-GMO uses the subclasses DataObject, FunctionMethod, Expression, ExpressionSegment and ExpressionOperator to express additional concepts reading data, operations and processes. DataObject class is used to define the used data, usually enriched with external ontologies describing the information data used for a specific project. Expression denotes a concept that consists of ExpressionSegments which indicate either an activity or a protocol. ExpressionSegments are connected via ExpressionOperator in order to compose a flow of actions that define the activity. FunctionMethod is designed in order to be instantiated as a method from software libraries. It is mapped to the external modules API methods for executing specific business logic functionalities.

MAS Implementation

The outcome of the design phase is the instantiated OWL-GMO where individuals are depicted by the agents and their functionalities. At the next step, being MAS implementation, the relative code of the agents will be generated according to JADE agent framework guidelines. In order to generate code, sets of "transformation" scripts are executed, which logic follows the main principles presented by Spanoudakis and Moraitis [START_REF] Spanoudakis | Gaia Agents Implementation through Models Transformation[END_REF].

In order to manage the data used by the agent system and depicted in the imported ontologies extending Data Object, the function createDataObjects() generates java classes based on the heredity feature which is supported by both OWL and Object oriented program languages. The create_literal_var() function creates a class public property of java common data type (String, int, etc) associated to DataProperty range type. The create_object_var() function creates a public property of the corresponding java class to ObjectProperty range ontology class. Java cardinality is defined by an array if there are multiple values. This transformation allows Java classes to be used in the generated code associated with the MAS definition. For the agent protocols that are released by attach_protocol_behaviour() function, the corresponding behaviors and ACL messages are generated according to the process flow defined by the related Expression. In each transformation the input and output data of behaviors are mapped according to Java data objects created by the function createDataObjects().

The next step is the gathering of all the external modules/java classes and adding them to the project classpath. The final step comes with the compiling and building of agent executable code that will run on top of an installed JADE platform at the enterprise environment.

Conclusion

The paper presents a framework relevant to the modeling, design, implementation and deployment of a MAS for the enterprise environment allowing the increase of its flexibility and decision making autonomy. In this context production process may be easier and more effectively decentralized. The different software tools are presented that make it possible to model the MAS in terms of ontologies, implement it and deploy it to the enterprise environment through Java code generation.

  depicts the system components of framework methodology software realization. The architectural components are:

	• Ontology Editor. It is GUI for composing and instantiating the ontologies used in
	the concept of the framework. Protégé tool (http://protege.stanford.edu/) is used for
	this purpose.
	• Ontology Importer. It is a module that manages the OWL ontology files composed
	by the Ontology Editor for a specific project (MAS definition). Furthermore, it
	keeps versions of the ontologies for potential use.
	• Code Generator is the component responsible for the transformation of the MAS
	definition to code running on top of JADE MAS platform. The Code Generator us-
	es an OWL Ontology Reasoner for the conceptualization -i.e. the identification of
	hierarchy and relations -of the imported ontologies. JENA semantic framework
	(http:// jena.apache.org) with Pellet (http://clarkparsia.com/pellet) reasoning sup-
	port is used for this purpose.
	• External Module Importer is a GUI responsible for collecting the external modules
	(binaries or code) needed for MAS implementation.

  Having generated the Java data object classes, the next step is the creation of the agents. In JADE framework agents are realized as extensions of jade.core.Agent and their tasks (activities or protocols) are implemented as a JAVA classes extending the jade.core.behaviours.Behaviour class. The received / sent messages for each agent are implemented using the jade.lang.acl.ACLMessage class. Function createAgents() depicts the code generation script for agents and their behaviors.

	Function createDataObjects():
	foreach (OWL Class) C
	if (OWL Class) C is subclass of (OWL Class) C1
	create_java_class_extends(C.name,C1.name)
	else
	create_java_class(C.name)
	endif
	for each (OWL DataTypeProperty) DP of (OWL Class) C
	cardinality = getPropertyCardinality(DP)
	create_literal_var(DP.name,C.name,cardinality)
	endforeach
	for each (OWL ObjectProperty) OP of (OWL Class) C
	cardinality = getPropertyCardinality(OP)
	create_object_var(OP.name,C.name,cardinality)
	endforeach
	endforeach
	Function createAgents():
	foreach (AgentRole as Agent)
	create_Agent(Agent)
	foreach (AgentActivity(Agent actsAccordingto)as
	Activity)
	Behaviour = create_Behaviour(Activity)
	attach_Behaviour_to_Agent(Behaviour,Agent)
	endforeach
	foreach (RolePermission(Agent interactsAccordingTo)as
	Permission)
	DataObject = getDataObject_isAllowed(RolePermission)
	attach_Data_Object_to_Agent(DataObject,Agent)
	endforeach
	foreach (AgentProtocol(Agent hasInitiator ||
	interactsAccordingTo|| hasResponder)as Protocol)
	Expression = getExpression_hasProcess(Protocol)
	attach_protocol_behaviour(Expression,Agent)
	endforeach
	endforeach


Aleksey Bratukhin
email: aleksey.bratukhin@oeaw.ac.at

Albert Treytl
email: albert.treytl@oeaw.ac.at

Thilo Sauter
email: thilo.sauter@oeaw.ac.at

MANU Building -Bringing together Manufacturing Automation and Building Automation

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Modern trends in automation require flexible production. While the current state of research shows a full range of solutions that satisfies mass customized dynamic production, it still assumes the constant level of energy consumption typical in centralized production with its long-time planning horizon. However, existing production systems focus on production costs minimization, but ignore increasing energy prices and the growing concern over the environmental impact of production systems.

Therefore, the new automation paradigm would require not only flexible production but also adaptable energy management of a factory.

Energy efficiency is widely discussed these days. However, most of the research and most of the new solutions offered are aiming at smart grid systems [START_REF] Singhal | Software models for Smart Grid[END_REF][START_REF] Dongli | Study on technology system of self-healing control in smart distribution grid[END_REF] or energy savings in commercial and residential buildings [START_REF] Cf | The quest for the ideal office control system[END_REF]. In particular there is energy saving by including the industrial building is not investigated and there is a high potential for savings. The "building" (HVAC, lighting, water, alarms and security, occupancy) consume 40% of the industrial energy [START_REF] Cf | The quest for the ideal office control system[END_REF].

There are two main demands on industrial buildings: (a) providing a controlled stable environment for the production process challenged by the modern dynamic productions and (b) minimizing the energy required for this. The MANUbuilding concept joins together the manufacturing system with the building automation to optimize the overall energy consumption of a factory. The seamless interaction between building and production is crucial to overcome mutual negative effects existing today.

The MANUbuilding concept increases energy efficiency in the manufacturing environment (factory as a building) by developing distributed intelligent control system integrating knowledge from the building sensor and actuator network integrated with the available resources on the shop floor with the predictive analysis of the factory behavior based on the production plans and shop floor schedules. The resulting system provides:

1) a production driven building control concept that adapts building energy profile and behavior to the dynamically changing requirement of the production system represented by the Manufacturing Execution System (MES)

2) a control concept for building-aware production that would integrate the energy saving requirements of the building into production planning.

These goals serve a double purpose of optimization of both the energy use and production system performance. The concept is based on three pillars:

1) Cooperating objects -a sensor network concept combining sensor and actuators with intelligence represented by collectors that connect together and provide intelligence to different parts of the system (sensors, actuators, resources, MES, ERP, SCM) [START_REF] Marron | European Research on Cooperating Objects[END_REF].

2) Function blocks -IEC 61499 is a modular, functionality based, event driven automation paradigm that is used as a platform for collectors implementation. It is the base for optimal integration in the production environment [START_REF] Vyatkin | The IEC 61499 standard and its semantics[END_REF].

3) Distributed local decision making based on the dynamic expanding clusters where data fusion mechanisms are applied to find solutions in the most efficient way.

A solution providing substantial energy savings of 20 to 60%, while at the same time not restricting the flexibility of production and offering a convenient engineering will have a success on a 25 billion euro market (global building-automation market).

Integration of production planning and manufacturing environment

The main benefit of the MANUbuilding is in advanced concepts for efficient energy use in industrial environment based on function blocks with intelligent nodes and distributed algorithms that combine the production optimization requirements with the building energy saving goals. Taking into account physical parameters of the factory floor and ERP and MES production schedules MANUbuilding uses data fusion concepts to produce an efficient and safe yet cost efficient system for online energy monitoring of industrial buildings. The two phase scenario of MANUbuilding allows making transition of existing system smoother: 1) In the first step the factory building adapts to the requirements of the manufacturing system, 2) And in the second step, the manufacturing system adapts its plans and behavior to consider energy needs of the factory. Therefore, existing factories are able to use the system without changing their entire enterprise. The core of the MANUbuilding architecture is the concept of dynamically expanding clusters that calculate locally so-called Energy Health Status (EHS). The term EHM is inspired by the state of the art paradigm of Structural Health Monitoring (SHM) where a sensor network monitors the structural integrity of a building structure.

EHM applies the principles of SHM to the energy monitoring area in order to determine integrity of the energy usage. EHM combines the concept of Cooperating objects with software agents' platform and energy efficient communication mechanisms, and applies net-centric, clustered multi sensor data fusion and processing algorithms to create a platform for online energy status retrieval.

Distributed decision-making based on dynamic clusters

The EHM approach focuses on recognizing and improving the Energy Health Status (EHS) of the system, where EHS is a resulting value of multiple calculations triggered by the events in the system that show the level of efficiency of energy use in a certain situation and location.

A simple example is when a user opens a window for full intermittent ventilation and temperature drops in a room. As a result a heater would start running. A simple solution to improve the EHS would be to stop the heater temporarily. In this way, the system can save the energy without interfering with user's intentions.

EHM system is based on expanding problem solving clusters to address the above mentioned drawbacks. Each cluster is a dynamically created community of intelligent components that cooperate with each to get enough information to solve a problem.

In case of the EHM, each member of a cluster has a set of algorithms that would allow recognizing an actual local EHS. In order to do so, it has to retrieve data from sensors and communicate with other members of the cluster to recognize and improve the EHS.

The initial creation of a cluster is trigged by an event that is predefined by the system developer or can be set by a user. In the case of the above given example, the cluster creation is initiated hen the window is open and the heater is on.

There is an endless number of scenarios possible from the very simple ones (as the above) to the very complex that involves regulation of the energy consumption on a scale of a complete building. The exact possible scenarios depend on the particular sensors related to an intelligent component as well as the location and designated tasks. The starting set of scenarios are assigned to a component during the initialization, but the new ones can be dynamically added during the system runtime when a new sensor or task is added to the system.

The key issue in developing such a system is flexibility and scalability of the solution. In EHM the problem solving approach is based on the expanding nature of the cluster formation and applied data fusion. Initially, there is only one member in the cluster that initiates and determines a problem. In the simplest case, its knowledge is sufficient to recognize the EHS and find an appropriate solution to improve it. But in the most cases it will require additional information and algorithms to improve the energy use efficiency.

Each intelligent component has a set of algorithms how to calculate and improve the EHS that has been assigned. And in order to do so, it needs to obtain information either from the sensors or from other intelligent units that also perform certain algo-rithms to calculate EHS. In EHM a brokering functionality is applied to find appropriate communication partners. Each system component publishes its algorithms and data points at the brokering component that manages the actual state of them via an event based update is triggered by the components themselves when a change in their algorithms occurs. The algorithm class description is encapsulated within a standard agent service description and can be understood by the collectors.

Hence, the system requires a very dynamic, flexible and scalable structure that includes both sensors and intelligent units to calculate the EHS.

System behaviour

EHM uses an emerging concept of Cooperating objects and sets its focus on sensor networks and distributed control that fits perfectly to fulfill the above mentioned requirements. Each Cooperating object consists of one or several sensors or/and actuators that are controlled by a collector. A collector is an intelligent component that has certain functionalities and is used in EHM for calculating the (local) EHS and participating in the cluster based solution finding. In the EHM architecture there are three main steps in a collector's behavior (Fig. 1):

1. Raw sensor data retrieved by the collectors via polling or event-based mechanisms are processed locally. A single collector can be responsible for monitoring multiple sensors and has an ability to process and aggregate data. 2. A collector recognizes a scenario and if the processed data is not sufficient to calculate the EHS then a collector creates a cluster by contacting other collectors to retrieve required information. Each collector, depending on its functionality, has different data fusion algorithms to recognize and calculate the EHS. 3. If the collector cannot determine the EHS, then it expands the cluster to include collectors with more advanced algorithms that use the results of other collectors' calculations to recognize the EHS.

4. The final step is a decision making how to improve the EHS and the following (5) commands to the actuators and reporting to the upper level system control. A flexible structure is one of the advantages of Cooperating objects concept that allow EHM to solve complex problems by including more collectors into the problem solving. Although, each collector in the EHM system is an independent acting entity, its position in the structure of the community is determined by the data management algorithms it can perform to calculate the EHS.

Some collectors in a cluster monitor one or few sensors and can only operate with the simple algorithms, on a higher level there are collectors that are not assigned to sensors but monitor other collectors and require the results of their calculations to perform more complex algorithms of their own. Due to the scalable structure of the Cooperating objects the number of collectors and resulting complexity is practically unlimited and hence allows the recognition of highly complex EHS.

However, it is important to mention that although the developed architecture allows dealing with complex algorithms requiring information from hundreds of sensors, in reality most of the situations can be dealt with a few collectors utilizing localized decisions.

All the computational and logical activities within the system are performed by the collectors making the choice of sensors and their integration into the system depend only on the ability to host the collectors. EHM uses sensors as hosts that provide the maximum flexibility to the system. Therefore, it is possible to spread the collectors over the existing sensor network.

The multi agent system that consists of a community of agents performing designated tasks as well as system components: an agent management system (AMS), directory facilitator (DF) and an interface to the upper level external system that allow EHM to implement a community of distributed collectors, provide a brokering functionality and use an existing communication platform [8].

Finally, data fusion and aggregation algorithms are applied to the collectors in context of software agents on WSN. Most data in monitoring are geographically or temporally correlated. And data redundancy can be avoided if the data were partially processed locally at the sensors by e.g., averaging it over time or space before forwarding [START_REF] Vyatkin | The IEC 61499 standard and its semantics[END_REF]. There are several functions that can be used in data aggregation and fusion along its way to collectors. Examples of such functions include average, maximum, minimum, sum, or deviation that can be applied periodically or on-demand, such as delay-bounded and power-efficient data aggregation protocols. Most of the data fusion and aggregation protocols to be used in WSN net-centric environment are either centralized or do not consider power or delay efficiency. EHM applies data fusion and aggregation to the local problem solving hence minimizing power and delay concerns resulting in higher efficiency of sensor data usage.

Two phase scenario for energy efficient industrial environment

The proposed approach offers two possible implementation scenarios that allow a smooth transition from the existing systems to the energy aware productions.

In the first phase, MANUbuilding provides a production driven control of the building automation system, where the MES schedule will have a priority and the building will adapt its behavior to best fit the production needs

The uniqueness of the MANUbuilding approach is the way production schedule is understood by the underlying building automation system. This direct control allows saving energy on the one hand by dynamic reaction to events of the shop floor and on the other hand by being able to pro-actively react to future events derived from the MES schedule. High savings by the latter are in particular expected for inert functions such as cooling.

Fig. 2. Production driven control of the building automation system

As shown on Figure 2, MANUbuilding acquires three times of information:

• Production plans from the ERP; general, long-term planning on the enterprise level that allows planning factory maintenance depending on the shop floor project ted load. In this case MANUbuilding is able to more efficiently keep the required energy conditions and make transitions in the factory state smoothly.

• Execution schedule from the MES; short-term (minutes to hours, sometimes seconds) plan how certain operations are executed on the shop floor. In this case MANUbuilding behaves similar to the previous case with the different planning horizon and more local conditions up to a work cell or a robot. That allows a fine tuning of the shop floor, efficient energy use and longevity of the factory equipment.

• Sensor data from the shop floor as well as from the factory building in general. If the situations described above were proactive, then this case is a reactive behavior of MANUbuilding allowing to react on the events and critical situations on the shop floor that would usually require human supervision and a long command chain involved. Shorter reaction time (starting from the faster recognition to the actual reaction) save not only the energy of the factory but improves the production efficiency in general.

Within the first stage, there is no influence on neither production plan nor execution schedule from the MANUbuilding. All the improvements on the Energy Health

Sensors

Status is implemented by the MANUbuilding system. The advantage of such a solution is the fact that practically any ERP or MES system can be utilized. However, the level of energy efficiency that can be achieved with the phase two is much higher.

Phase two implements a building-aware production system where both a building and the production planning will have mutual influence on the integrated system behavior combining production and energy cost parameters as criteria for system optimization. In this case, not only the building adapts to the production system, but also MES adapts it schedule to minimize the overall energy consumption of the complete factory (shop floor and surrounding building). Although not shown on Figure 3, phase two incorporates the activities of the phase one. Figure 4 only shows the extra communication that is performed during the phase two. The principal difference of phase two compare to phase one is that the production system considers energy requirements of the factory building in planning and operation execution. The mechanism is the following:

1. MANUbuilding sends long-term building energy requirements to the ERP system for the production plan decisions. Then it is a responsibility of the ERP system how to interpret this information: whether to include it into the planning or not. That requires the adjustment of the ERP system to be able not only to communicate with the MANUbuilding but also a set of rules and decision making procedures are required to implement MANUbuilding concept. Eventually, the energy requirements are passed down the MES system with the adapted production plan. 2. In addition to the long-term planning requirements, MANUbuilding sends events to the MES system to react on the changing energy profile of the factory during the runtime of the manufacturing system. These events are local and focused on particular sections or elements of the factory that change overtime. As with the ERP system it is up to the MES how to react to the events. And the MES system has to be adapted to be able to handle the communication and decision making procedures.

3. Finally, MANUbuilding itself may serve as management system on the same level as MES and issues commands to the shop floor to adapt to the energy requirements of the factory. Although, it might cause a conflict of interest in centralized MES solutions, recent developments towards distributed manufacturing systems are perfectly suited to handle such situations in a flexible, smooth and efficient way.

Outlook

The presented architecture bring together factory building management with the manufacturing system, but including factory energy requirements in the optimization decisions of the ERP and MES systems adjusting the formula of the total production costs that usually neglect energy costs of the production or count them as constant and therefore cannot be optimized. The efficiency of the system lies in net-centric problem solution clusters that only extend themselves to larger aggregations if a problem cannot be solved on a local basis.

Two-phase solution offers flexible way of integrating MANUbuilding into existing systems without considerable changes to the already functioning environment.

However, the potential of MANUbuilding can be fully exploited in distributed manufacturing system, where MANUbuilding would be an integral part of planning and execution process, therefore, integrating energy costs and environmental concerns into the total production costs as a main criterion for optimization in manufacturing.

Fig. 1 .

 1 Fig. 1. Collector behavior

Fig. 3 .

 3 Fig. 3. Building-aware production system