Mock article for Studia Informatica

Transkrypt

STUDIA INFORMATICA
Volume 37
2016
Number 4A (127)
Udo WOZAR, Huseyin ERDOGAN,
Conti Temic microelectronic GmbH, Ingolstadt, Germany
Rafal CUPEK, Szymon ZIEMEK
Silesian University of Technology, Institute of Informatics, Gliwice, Poland
APPLICATION OF ISA95 DATA MODELS IN MANUFACTURING
EXECUTION SYSTEMS FOR LEAN PRODUCTION
Summary. Manufacturing Execution Systems (MES) are service-oriented
interfaces that join the word of business transactions with the world of production
systems. Nowadays IT systems have to provide very detailed information that is
related to an underlying production process and also to actual product. There are a few
emerging business models that require accurate and timely production data. This
document examines two approaches to database architecture that can be used in
Manufacturing Execution Systems (MES). It focuses on the support of the LEAN
business model. The main research goal is to support the flexible access to production
data, but the efficiency of database is also very important factor. Authors compare the
classical relational database model with the object-oriented one. Considered use cases
include the Oracle DB and Oracle Objects applications for MES. Presented object
oriented approach follows the ISA95 standard. The practical use cases are based on
the production of electronic devices carried out by the company Continental
Ingolstadt. Although object oriented databases are not well accepted by the industry
due to their low efficiency, the authors show that in the case of LEAN production, the
database system based object-oriented models can be far more convenient than a
classical relational database. The main benefits are more flexible data model and
highly adjustable MES that can follow changes in the underlying production system.
By the case of LEAN manufacturing, authors show that the flexible object oriented
database is more efficient solution comparing to the relational database. Moreover
such an approach can help to avoid well known big data problems that are common in
classical MES.
Keywords: MES; Manufacturing Execution System; LEAN production; ISA95
34
U. Wozar, H. Erdogan, R. Cupek, Sz. Ziemek
ELASTYCZNE MODELE DANYCH ZGODNE ZE STANDARDEM
ISA95 DLA SYSTEMÓW REALIZACJI PRODUKCJI KLASY MES
Streszczenie. Systemy realizacji produkcji klasy MES (Manufacturing Execution
Systems) dostarczają zorientowanych na usługi interfejsów informatycznych, które
łączą świat transakcji biznesowych ze światem systemów produkcyjnych.
Współczesne systemy informatyczne stosowane w przemyśle przekazują bardzo
szczegółowych danych, które opisują zarówno samą realizację procesu
produkcyjnego, jak i właściwości wytwarzanych produktów. Jednocześnie pojawiają
się nowe modele biznesowe, które wymagają dokładnych i aktualnych danych
produkcyjnych. Niniejszy dokument porównuje dwa podejścia do architektury baz
danych, które mają być wykorzystane w systemach realizacji produkcji klasy MES
współpracujących z systemami biznesowymi bazującymi na modelu LEAN. Głównym problemem jest zapewnienie elastycznego dostępu do danych produkcyjnych,
tym niemniej wydajność systemu i szybki dostęp do gromadzonych danych są także
istotnymi czynnikami wpływającymi na wybór architektury systemu. Rozpatrywane
przypadki użycia obejmują zastosowanie rozwiązań Oracle DB i Oracle Objects
w systemach MES. Podejście obiektowe zilustrowano na rozwiązaniach opartych na
standardzie ISA 95. Przedstawiona analiza została zilustrowana przez prezentację
przypadków użycia zaczerpniętych z obszaru produkcji zaawansowanej elektroniki
samochodowej realizowanej przez firmę Continental Ingolstadt. Zastosowanie
obiektowego modelu bazy danych w przemyśle jest w chwili obecnej bardzo
ograniczone ze względu na niską wydajność dostępnych rozwiązań. Autorzy
wykazują, że w przypadku systemów MES wspierających model biznesowy „LEAN
production” zastosowanie podejścia obiektowego pozwala na elastyczne dopasowanie
interfejsu systemu bazodanowego zarówno do modelu biznesowego, jak i do formatu
źródeł danych na poziomie systemu produkcyjnego. Ponadto, podejście obiektowe
umożliwia ograniczenie nadmiernego rozrostu wolumenu danych (Big Data problem)
Słowa kluczowe: MES; Manufacturing Execution System; LEAN; ISA95
1. Introduction
Nowadays control systems provide very detailed information that is related to an
underlying production process [1]. This information is further used by Business Intelligence
systems, which are localised on the Enterprise level. Manufacturing Execution Systems
(MES) are service-oriented interfaces that joins these two worlds. MES offer sets of
interfaces that connect the physical world of production with the virtual world of business
transactions. The classical MES are defined by their static hierarchy, which makes them very
Application of ISA95 Data Models in Manufacturing…
35
difficult to modify. This issue forces the research on a new approach to the architecture of an
MES that will support the huge stream of information that is exchanged between business and
production systems [2].
The commonly accepted definitions of MES functions and standards can be found in the
sets of documents that are managed by MESA International (Manufacturing Enterprise
Solutions Association), which is a worldwide not-for-profit community of manufacturing
companies, information technology hardware and software suppliers, system integrators,
consulting service providers, analysts, editors, academics and students [3]. According to
MESA’s definition, MES support production in the following activities: job scheduling,
launching the orders, responding to random events, adjusting production plans, tracing
product genealogy, managing production quality and managing maintenance activities. The
above-mentioned areas are systematised into conceptual and functional models which are
described the in ANSI/ISA-95 (IEC/ISO 62264) standard that is the international standard for
the integration of enterprise and control systems [4].
ISA-95 defines the MES data structure and MES services that are related to
manufacturing operations: defining the product, forecasting production, managing production
capability and evaluating production performances. ISA-95 consists of models and
terminology and describes the information that is exchanged between the systems for sales,
finance and logistics and the systems for production, maintenance and quality. This
information is structured in the form of UML (Unified Modelling Language) models, which
are the basis for the development of standard interfaces between ERP (Enterprise Resource
Planning) and MES systems.
Nowadays production series become shorter and MES has to operate with masscustomised production. Moreover production systems become more autonomous and MES
architectures must follow these changes [5]. The underlying database system efficiency is not
such a problem like data structure flexibility and ability to adjust changes in production
system environment[6]. To ensure enough flexibility ISA-95 models are built on the objectoriented paradigm used to define the interface between control systems and business
application. ISA-95 defines the services that are required for the manufacturing support that is
designed according to the object-oriented model [4]. These services are not only based on
information exchange but also on the aggregated data or the history of the realisation of the
process that has to be managed by database systems.
Another issue is communication with database in MES. The desktop clients are due their
low mobility obsolete. New Object oriented standards and services has to be implemented. A
good example is OData protocol that can reduce the volume of information exchanged
between client and servers [7]. Instead of processing big data sets[8] by client the information
36
processing can be more effectively done by servers but new client server paradigm has to be
established – interactive services replace exhausting data queries. OData becomes that foe
web applications what SQL for Database systems is. As is shown in [9], the growing amount
of data that is processed by industry has created the necessity to create the right approach and
tools to convert the data into useful, actionable information. As a result, a huge amount of
data has to be stored in the database systems that support ISA95 standard.
The main goal of this paper is to present the comparative research study on relational
database and object database architectures used for ISA95 based MES. The use case analysis
was based on the example related to managing materials that are used in the production of
electronic devices. The authors compare two different approaches including the classical data
representation in a relational database and the object-oriented data representation that directly
reflects the ISA-95 models and is realized as an object-oriented database. The authors applied
for MES database system the classical Oracle and Oracle Objects. The advantages and
disadvantages of both solutions including comparison in efficiency, size of data that is stored
and the time that is required to perform operations on the data are presented in the
experimental part of this paper.
The paper is organised as follows: the discussion on applying the LEAN manufacturing
approach not only to save physical resources but also to make their representation in database
more close to its object based nature is presented in chapter one. Because the costs of
database application are also related to cost of its maintenance and time necessary for changes
adoption, the dependency between Lean manufacturing and Lean Database, is considered
during selection of data base model as presented in the chapter two. Chapter three presents a
practical use cases of MES databases and the comparison of the efficiency. The conclusions
are presented in chapter four.
2. Database model
“A model is a useful representation of a specific situation or thing. Models are useful
because they describe or mimic reality without dealing with every detail of it. They typically
help people analyse a situation by combining a framework’s ideas with information about the
specific situation being studied.” [10]. The biggest challenge today is not only to make the
data "LEAN", but also to allow enterprises and customers to speak the same language, which
means reducing the information exchange time and complexity for this process. It is very
important that each side can quickly understand the information that is received. One
37
component that can complement the architecture of a system with a complete, comprehensive
and easy to exchange data model is the ANSI/ISA-95 standard.
In general, ISA-95 defines the MES data structure and MES activities that are related to
manufacturing operations: defining a product, forecasting production, managing production
capability and evaluating production performances. ISA-95 consists of models and
terminology and describes the information that is exchanged between systems for sales,
finance and logistics with the systems for production, maintenance and quality. This
information is structured in the form of UML (Unified Modelling Language) models, which
are the basis for the development of standard interfaces between ERP (Enterprise Resource
Planning) and MES systems [11].
What is interesting is that the second part of ISA-95 introduces one common data model
that includes all of the possible functionality that may be needed in enterprises. Enterprises
can follow this model to ensure data consistency not only within the enterprise but even in a
network of companies. This model is very easy to introduce. It consists of smaller models that
are defined as UML diagrams. Each class from the diagram is widely described as the general
idea for a given class and all of its attributes. We can assume that ISA-95 is an objectoriented model, so the conclusion is that maybe we should try to use an object-oriented
database. Because the structure of ISA-95 models is defined in an object-oriented way, it
seems that the most convenient physical representation should also be a database system that
is organised in an object-oriented way.
An Oracle Database, which is commonly referred to as Oracle RDBMS or simply as
Oracle, is an object-relational database management system that is produced and marketed by
the Oracle Corporation. PL/SQL, which is the Oracle procedural extension of SQL, is a
portable, high-performance transaction-processing language[12]. With objects, users can
break complex problems down into easily understandable object methods within object types.
Using object types in a PL/SQL block subprogram or package is a two-step process that
involves:

defining the object types using the SQL statement CREATE TYPE. After an object type
is defined, users can use it in any PL/SQL block, subprogram or package;

declaring the variables for the user-defined object types in PL/SQL. After the variables are
defined, users can refer to the proper methods that were declared for a given variable.
New object types can be created from any built-in database types and any previously
created object types, object references and collection types. Object types can work with
complex data such as images, audio and video. An Oracle Database stores the metadata for
user-defined types in a schema that is available to SQL, PL/SQ, Java and other languages.
38
This is one big advantage of the object model – users have the data and its description in one
location [7]. Using objects has three very important advantages:

encapsulation – only the necessary data and methods are available outside an object and
the rest is hidden in the object structure. Users have a plain interface without any
redundant data or methods and can easily use it;

efficiency – all object members and methods are defined inside the database. This ensures
that all of the structures are available and ready to use at any time. Developers do not need
to create object definitions in their applications because they can use the objects that are
already defined;

simplified logical structure – it is more convenient and natural to organise a data structure
using objects (e.g., a car object that includes the objects of its components) that represent
real-life things.
The final point is about the architecture of a database. In general, the two most popular
architectures are central architecture and distributed architecture. An illustration of the
concept of a centralised MES architecture is presented in Fig. 1. A central database governs
all production data. Data access can be supported by stored procedures that are executed on
the database server, which allows all of the business logic to be placed inside the database.
Such a solution has the following advantages: better performance – all queries can be
executed faster; a programmer does not need to implement functionality inside applications
and the data is always consistent.
Fig. 1. An example of centralized MES database architecture
Rys. 1. Przykład scentralizowanej architektury systemu klasy MES
39
The main drawback of a centralised database architecture is the difficulty and high risks
that are connected with any change in its structure. Production process modifications are
relatively rare in mass production systems and classical architectures are used because of their
efficiency. Nowadays, manufacturing is extremely competitive in most industrial sectors and
the financial margins that differentiate between success and failure are very tight [13,14].
This means that it is very difficult to fill volatile market demands without an effective and
flexible Manufacturing Execution System.
A flexible MES should meet objectives that are connected with reconfigurable machinery
and robots and should be capable of easy adaptation to production requirement changes,
which are very characteristic in contemporary production models. Specific components of
flexible MES systems should be decentralised, autonomous and supported by service-oriented
communication protocols. A database should provide the interfaces that are necessary to
communicate with the different workstations that realise the individualised paths of
production flow. This requirement should be extended to production lines and should reflect
flexible configurations as well as changes in production scenarios. Flexibility at the MES
level has to be supported by a flexible information structure and by an extensible and objectoriented underlying database system.
Another database problem is availability. Data should be stored in one place only and this
place should be available at all times. To ensure that data is safe and will always be available,
cyclical backups must be made. The main issue in distributed database architecture is
synchronising the data between databases. The next important feature is the ability to store
the metadata that describes the location and localisation of the data that is processed by an
MES system. Metadata can be stored in an additional separate place and managed by
additional agent components that support the MES system in database access. The idea of the
distributed MES database that is described above is presented in Fig. 2.
The biggest advantage of a distributed approach is that data can be distributed and backed
up in different locations. Distributed and redundant data are safer (the main part of data will
still be available even when parts of the system fail) but with an additional cost in system
performance and the need for additional data management functionalities.
Communication between databases and other stations can be done using the same
protocols that are used in centralised architecture. In this case, part of functionality can be
implemented as stored procedures in databases. The rest of the system logic can be
implemented by MES agents. This can cause distributed architectures to work more slowly
than centralised ones. Another problem can occur with data consistency since functionality
and data structures are defined in different locations. To avoid this problem, an MES should
follow a clear and unequivocal data structure and unified data representation. According to
40
the ISA-95 standard, an application data model seems one of the more promising solutions to
fulfil this requirement in a distributed MES.
Fig. 2. An example of distributed MES database architecture
Rys. 2. Przykład rozproszonej architektury systemu klasy MES
3. Models comparison of use cases with electonic devices production
Two similar applications were prepared. The first one was prepared using a usual
approach (using a relational database and an often-used approach to model the data) and the
second one was prepared using the ISA-95 standard implemented as an Oracle Objects model.
The application was prepared as a database- centralized system, which means that all of the
functionality is included in a centralised database as storage procedures or as member
functions in objects. It was done this way for two reasons. It allows programmers to change
the technologies that are being used (in GUI applications) without the need for changes in
functionality and also it allows some database tests to be performed without any influence of
the network or connections. A short comparison between both applications and their data
models done is presented in this chapter. For transparency and to provide a better
understanding, it will be prepared using only a small part of the "Production operations
management information" model, which is defined in the first part of the ISA-95 standard
(Models and Terminology) [15] – Product definition.
41
To make this comparison more understandable, we can describe a real example of how
the Product definition functionality works. The Short Range Radar 200 is used as the example
device. The Short Range Radar 200 is a device that is part of the safety features in a car. As
we can see on the Fig. 3, the SRR200 is simply a small black box with mounting wings and a
connector.
Fig. 3. Exploded Short Range Radar, model SRR 200
Rys. 3. Schemat budowy radaru krótkiego zasięgu, model SRR 200
During the production process, it is necessary to know the structure of the device and all
of the sub-materials. In the example that is given, we can see that the SRR 200 consists of
five sub-materials: Housing, RF Antenna board, EMC Shield, PCB and Back Cover.
Precisely that information (of course with more details) should be stored in the product
definition application. In addition, we can assume that the SRR200 consists of other
materials, and that it can also be defined as a sub-material for other materials (e.g., a car). If
necessary, this information can also be stored in the product definition. Now the question is:
How to store and manage this data?
Relational databases are well known and deeply explored mechanisms. In this approach,
programmers must think in terms of tables, relations, etc. The authors want to show the bad
habits of programmers, which cause the project to become huge and inconvenient for
providing any additional functionality. This approach leads us to "big data" that is not
expected and that is difficult to apply to data mining methods with a good performance. A
typical data model in this case looks like the model in Figure 4 (only the most important part
of the whole model shown) here.
The materials table is the most important table. As we can see, material has its own id,
description and some other static properties such as product type, location or additional
properties. Relations between materials are made by using a material_use table in which a
parent and its child can be defined. This model should be surrounded with some functionality,
42
which is done using storage procedures that are grouped within a package. After such a model
was defined, some tests were performed, which will be described later.
Fig. 4. Database structure for the first approach
Rys. 4. Struktura bazy danych dla pierwszego podejścia
An Object-oriented database using ISA-95 approach is slightly different. Users do not
have to think in the term of tables, but rather in term of "real objects". This means that users
don't need to worry about the database structure, but only about what kinds of properties he
wants to assign to a given material. Tables are only created to store the list of objects.
Moreover, Oracle objects themselves are nothing more than a kind of "interface" with a
relational engine behind them. So why have the authors decided to focus on objects? The first
point is that objects are very convenient and much easier to understand, even for
programmers who are working with them for the first time. The second point is that objects
can be implemented using the ISA-95 standard. The ANSI/ISA-95 is the standard that leads
us to less data. Why? Because the data that is required in the models are minimised in most
cases to just two fields – Id and description. If some other fields are needed, they are added as
dynamically assigned properties. The attributes of the model are described in detail in the
second part of the standard [16]. We can say that the idea of using Oracle objects together
with the ISA-95 should lead us along a common path with the LEAN methodology [17,18].
In order to check the accuracy of the sentence above, an object-oriented model was
prepared. The base for the model was a part of the Material model, which is defined in the
second part of the ISA-95 standard (Fig. 5). Four classes are defined: Material class, Material
definition, Material class property and Material definition property.
43
Fig. 5. Material definition part of the Material model of ISA-95
Rys. 5. Diagram definicji materiału według modelu w standardzie ISA-95
Using the standard attributes and connections that are defined for each of the four classes
[16], a user can define the structures of the objects in the database (Fig. 6).
CREATE OR REPLACE TYPE material_t AS OBJECT
(
mat_NO VARCHAR2(100),
description CLOB,
CONSTRUCTOR FUNCTION material_t(I_mat_NO VARCHAR2, I_description
VARCHAR2) RETURN SELF AS RESULT,
MEMBER FUNCTION get_property_value(I_prop_name VARCHAR2)
RETURN VARCHAR2,
MEMBER PROCEDURE set_property_value(I_prop_name VARCHAR2, I_prop_value
VARCHAR2),
MEMBER PROCEDURE add_to_class_list,
MEMBER PROCEDURE add_to_definition_list
MEMBER PROCEDURE remove_from_list );
Fig. 6. Definition of material object type
Rys. 6. Implementacja struktur reprezentujących informacje o materiale
44
Three tables created to store the list of the material class, material definition and its
material properties:

MATERIAL_CLASS_TAB

MATERIAL_DEFINITION_TAB

MATERIAL_PROPERTIES_TAB.
With such a defined model, the functionality and data are quite similar to the application
from the first approach and a comparison between them can be done. Working with this
model is just like working with objects in C++ – users simply execute the object’s member
functions. The comparison was done based on several fields: data size and data redundancy,
model flexibility (possibility to extend the model) and performance. The results are presented
in Table 1. The performance results were obtained as a time measurement for the following
operations: insert, update and delete. Fifty of the following tests were done for each of those
operations:
− time for the operation for 1 record
− time for the operation for 100 consecutive records
− time for the operation for 1000 consecutive records
− time for the operation for 10000 consecutive records.
Each total time was divided by the number of records in the operation and the average
value for the operation for one record was taken. The following figures present the time
results for each of the tests as the average time needed for one operation. In the figures above
we can see that the times for the insert and update operations are much better for relational
approach. On the other hand, the times for the delete operations are slightly better for the
object approach. Only a part of the ISA-95 model was tested. The whole model and all its
properties would certainly take more physical disk space, but they would also provide more
knowledge about the model and the metadata, which could be helpful when the data would be
analysed (data mining).
45
Results of the comparison
Approach 1:
Approach 2:
Relational database
Oracle Objects with ISA-95
Tables’ sizes after inserting 10000 records:
3 211 264 Bytes
1 835 008 Bytes
Huge size of the MATERIALS table. A
large amount of data redundancy
because each material has own list of
properties, even within the same
material class.
Dynamically defined
(user can simply add a new property to
the list)
ISA-95 provides a very flexible model.
To extend it, a user can just add a new
property (which consists of Id,
description, value and measure unit). In
the event of a strong need, a user can also
add a new field to the previously defined
object types.
Results are the average values for one operation taken from the results for 1, 100,
1000 and 10000 operations:
INSERT: 0.0002258 s
INSERT: 0.0010298 s
UPDATE: 0.0024325 s
UPDATE: 0.0056245 s
DELETE: 0.0017900 s
DELETE: 0.0012303 s
This approach is good if the company
sells only one product during its whole
life, but is not good for corporations in
which products evolve. However,
unfortunately, it is still often used.
Extending the
model
Performance
test
Statically defined
Less data, the main properties are
assigned to the material class. Materials
contain only unique properties and
property with class id.
Comments
Material
properties
Physical data size
Table 1
Model is static. To extend it, the
database structure needs to be changed.
Slightly slower (performance), but very
flexible. A good way to implement a data
model that is easy to extend. ISA-95
ensures consistency of the data.
4. Conclusions
In this document, the authors have presented the LEAN MES approach, which can be
realised in practice using the Oracle Objects database together with the model definitions
given by the ANSI/ISA-95 standard. As shown an curtail issue for ISA-95 implementation is
46
the flexible database approach that allow for LEAN implementation of ISA-95 models. An
object-oriented application is not a high performance solution especially in the case of the
time necessary for the realisation of INSERT and UPDATE operations.
Fig. 7. Time results for the insert operation
Rys. 7. Wyniki pomiarów dla operacji wstawiania nowych rekordów
Fig. 8. Time results for the update operation
Rys. 8. Wyniki pomiarów dla operacji aktualizacji rekordów
On the other hand the object oriented database is represented in more compact way and
takes up less disk space than its relational equivalent. The main advantage of the object
oriented database model is its flexibility. In the case when time for database operation is not
critical (like for example in the case of MES for short series production) the cost of big
efforts related to data model adjustment in the case relational database can be far more
47
unfavourable than benefits from fast data access. ISA95 and its object oriented
implementation offer ready to extend data models without the need to change the database
structure. To successfully implement IS95 model in object oriented database it is necessary to
make a fusion between an object-oriented database engine and ISA95 models. Such a fusion
will lead to the unified MES information flow model and results in a flexible Manufacturing
Execution System that supports both the business and production levels.
Fig. 9. Time results for the delete operation
Rys. 9. Wyniki pomiarów dla operacji usuwania rekordów
Presented research results show the relation between selected database type and the
efficiency of the data access. As shown by the experiments, in the classical relational database
is slightly more efficient than object oriented one. On the other hand, even in the case of
Oracle objects, the particular operation time is measured in fractions of a second. The main
benefit from object oriented architecture is its flexibility. It means that system designer will
spend less time on changing the underplaying database structure, in the case when changes in
MES are necessary. Since, MES do not work as real-time systems, authors conclude that
benefits from system flexibility are more significant than slightly longer database access time.
Acknowledgements
This work was supported by the European Union from the FP7-PEOPLE-2013-IAPP
AutoUniMo project “Automotive Production Engineering Unified Perspective based on Data
Mining Methods and Virtual Factory Model” (grant agreement no: 612207) and research
work financed from funds for science in years 2016-2017 allocated to an international cofinanced project (grant agreement no: 3491/7.PR/15/2016/2).
48
BIBLIOGRAPHY
1.
Shipp S.S., Gupta N., Lal B., Scott J.A., Weber C.L., Finnin M.S., Blake M., Newsome
S., Thomas S.: Emerging global trends in advanced manufacturing, DTIC Document,
2012.
2.
Blanc P., Demongodin I., Castagna P.: A holonic approach for manufacturing execution
system design: An industrial application. Engineering Applications of Artificial
Intelligence. Volume 21, Issue 3, April 2008, p. 315÷330.
3.
http://www.mesa.org
4.
http://www.isa-95.com
5.
Cupek R., Erdogan H., Huczała Ł., Wozar U., Ziębiński A.: Agent Based Quality
Management in Lean Manufacturing. In Computational Collective Intelligence,
Springer 2015, p. 89÷100.
6.
Do N.: Integration of engineering change objects in product data management databases
to support engineering change analysis. Comput. Ind. 73, 2015, p. 69÷81. DOI:
10.1016/j.compind.2015.08.002.
7.
Cupek R., Huczała Ł.: OData for service-oriented business applications: Comparative
analysis of communication technologies for flexible Service-Oriented IT architectures.
IEEE International Conference on Industrial Technology (ICIT), 2015, p. 1538÷1543.
8.
Lee J. et al: Recent advances and trends in predictive manufacturing systems in big data
environment. Manufacturing Letters 1.1 (2013), p. 38÷41.
9.
Choudhary A.K., Harding J.A., Tiwari M.K.: Data mining in manufacturing: a review
based on the kind of knowledge. Journal of Intelligent Manufacturing, October 2009,
Volume 20, Issue 5, p. 501÷521.
10.
Anvari A., Ismail Y., Hojjati S.M.H.: A Study on Total Quality Management and Lean
Manufacturing: Through Lean Thinking Approach, 2011.
11.
Alter S.: Information Systems. Pearson, Upper Saddle River 2002.
12.
Oracle
Database
documentation
Library.
12c
Release
1
(12.1).
http://docs.oracle.com/database/121/index.htm. 2014.
13.
Bleeker A.: Prozessoptimierung in der Produktion heute. Productivity Management,
März 2012, p. 24÷26.
14.
Charantimath P. M.: Total Quality Management. Pearson, 2011.
15.
ANSI/ISA-95.00.01-2010. Enterprise-Control System Integration – Part 1: Models and
Terminology. Approved 13 May.
16.
ANSI/ISA-95.00.02-2010. Enterprise-Control System Integration – Part 2: Object
Model Attributes. Approved 13 May 2010.
17.
49
Gerberich T.: Lean oder MES in der Automobilzuliefererindustrie. Gabler, Chemnitz
2010.
18.
Shang Gao S.P.L.: Lean Construction Management – The Toyota Way. Springer,
Singapore 2014.
Omówienie
W niniejszym dokumencie, autorzy przedstawili przykład zastosowanie obiektowego
modelu bazy danych w połączeniu ze standardem
ISA95 w systemach klasy MES.
Zaczerpnięte z produkcji elementów elektronicznych przykłady ilustrują problem efektywnego wykorzystania systemów realizacji produkcji do wsparcia produkcji krótkoseryjnej
z uwzględnieniem wymagań modelu biznesowego „LEAN production”. Przeprowadzone
badania obejmowały wykorzystanie bazy danych Oracle Obiects do implementacji modeli
danych definiowanych przez standard ISA-95. Przeprowadzono analizę wydajności modelu
i porównano go z analogicznym systemem zrealizowanym w klasycznej architekturze
relacyjnej bazy danych. Wyniki praktyczne wskazują, że bezpośrednia implementacja modelu ISA-95 w obiektowej bazie danych jest mniej efektywna niż analogiczna funkcjonalność
uzyskana w technologii relacyjnej. Różnice widoczne były szczególnie w przypadku czasu
niezbędnego do realizacji operacji INSERT i UPDATE.
Obiektowy model bazy danych ma bardziej zwartą strukturę i przechowywane dane zajmują mniej miejsca na dysku niż w przypadku systemu opartego na bazie relacyjnej. Główną
zaletą modelu obiektowego jest jego elastyczność. W przypadku gdy czas operacji bazodanowych nie jest krytyczny dla produkcji (jak ma to miejsce na przykład w systemach MES
wykorzystywanych w produkcji krótkoseryjnej), czas i koszt operacji związanych z dostosowaniem modelu danych do profilu produkcji niezbędne dla baz relacyjnych mogą być o wiele
bardziej kosztowne niż korzyści wynikające z szybkiego dostępu do informacji. Zaletą standardu ISA 95 oraz jego implementacji w obiektowej bazie danych jest skalowalność modelu
danych bez konieczności zmiany struktury bazy. Do skutecznej implementacji standardu
ISA95 konieczna jest fuzja pomiędzy silnikiem bazy relacyjnej i modelem ISA95. Dopiero
takie rozwiązanie pozwoli na efektywną realizację zunifikowanego modelu przepływu
informacji zaproponowanego przez standard ISA95. Umożliwi to realizację systemów klasy
MES z uwzględnieniem zarówno wymagań elastyczności modelu biznesowego, jak i wysokiej wydajności operacji na bazie danych.
50
Addresses
Udo WOZAR: Conti Temic microelectronic GmbH, Ringlerstraße 17, 85057 Ingolstadt,
Germany, [email protected]
Hueseyin ERDOGAN: Conti Temic microelectronic GmbH, Ringlerstraße 17, 85057
Ingolstadt, Germany, [email protected]
Rafal CUPEK: Silesian University of Technology, Institute of Informatics,
ul. Akademicka 16, 44 100 Gliwice, Poland, [email protected]
Szymon ZIEMEK: Silesian University of Technology, Institute of Informatics,
ul. Akademicka 16, 44 100 Gliwice, Poland, [email protected]

Mock article for Studia Informatica

Transkrypt

Podobne dokumenty

RESEARCH MANAGEMENT EXECUTIVE IN

You Go To My Head - Rod Stewart - tekst

(Equity)Portfolio Manager

Sales support / Warehouse support

Temporary Customer Assistant Nr ref