5 Building an MES system
5.1 Software architecture of an MES system
The architecture of modern MES systems is also oriented like other busi-ness solutions by the so-called “busibusi-ness service architecture” or “enter-prise service architecture” (ESA for short). An important reason for select-ing this architecture is that durselect-ing the life cycle of an MES system new demands are continually arising which need to be implemented in a virtu-ally never ending process.
The individual layers of the architecture of a modern MES system and their special features are explained in the following sections.
In addition to ensuring the delivery of predominantly technical proper-ties, both the architecture and the basic functions of an MES system have a special importance. Provided that both the architecture and also the basic functions are properly defined and implemented and the basic functions are oriented to the standards usual in the market, this will form the best conditions for an open, expandable and future-proof system.
5.1 Software architecture of an MES system 101
Fig. 5.1. The software architecture of an MES system
This is why many proprietary systems suffer from the lack of a global ar-chitecture or from the absence of any way of allowing new technologies to feed in rapidly and smoothly within the basic functions without unwanted effects on the applications themselves and thereby constituting an IT risk.
5.1.1 Basic functions
The basic functions of an MES system are a collection of software functions which are available independently of a particular product and which enable the products based on them to be developed as far as possible using the same modules and with a uniform structure. As has already been shown in the previous section, a good basic functionality allows technologies to be in-corporated or replaced without this affecting the individual products.
The basic functions will therefore provide separation of the MES appli-cations from the technical components which form the basis of any IT sys-tem. In practice the users, often compelled by corporate policies, want a change in the operating system, a change in the database system or a change in the communication protocols for their MES application. These
102 5 Building an MES system
modification requirements alone also demonstrate the fast-changing nature of the IT sector and show how important it is that modifications of this kind do not, if at all possible, have any effect on the applications themselves.
In more detail, the most important functions and objective of the basic function are these:
Provision of a uniform interface to the underlying database with the aim of securing database independence. A modern MES system supports several SQL database systems. The most important of these are Oracle, Microsoft SQL Server and also the IBM databases Informix and DB2.
Database independence is particularly important to an MES system since, due to costs for licenses and administration expenses, it is then a simple matter for the user to swap database systems.
Provision of a uniform interface to the underlying operating system with the aim of securing operating system independence. The leading operat-ing systems in which MES systems can be used are Microsoft Windows, Linux and also the Unix derivatives IBM AIX, HP UX and Sun Solaris.
The reasons for not being tied to a particular operating system are often the same as for database independence.
Provision of communication facilities Examples:
Secure network communication on the basis of TCP/IP
Bus systems in production
Provision of components for typical MES tasks Examples:
Components for displaying business diagrams
Components for the temporary storage of data
Components for the secure acquisition and checking of data
Provision of interfaces and functions for incorporating products with the components data layer, application layer, and process mapping.
Provision of separate database partitions for OLTP1 and long-term stor-age to ensure response times on the one hand as well as medium- and long-term availability of data on the other hand.
Provision of technologies for interfaces Examples:
Web services
OPC
Excel export or XML export
Various file formats
1 OLTP is an acronym for online transaction protocol and is used here as a synonym for the real-time database section of an MES system
5.1 Software architecture of an MES system 103
Product-independent alarm system with the corresponding communica-tions terminal points, email, cell phone, pager and so on (so-called esca-lation management).
Functions for logging, monitoring and tracing (for example, for the rapid detection and locating of fault states).
For an open system it is also important for the MES manufacturer to keep some of his interfaces open, particularly for those interfaces and functions relating to integrating products. If this is the case, then partners or even IT-savvy users will potentially be able to integrate their own appli-cations into the existing MES system.
Especially when an MES system is used in food or pharmaceutical in-dustry it is subject to additional technical requirements relating to so-called
“FDA conformity” which will ideally already be reflected in or at least supported by the basic functions of an MES system. In addition, a supplier of suitable MES systems to the food and pharmaceutical industries will have knowledge and experience of engineering and developing software in conformity with FDA requirements.
5.1.2 Data layer
The data layer is that part of the MES application which is responsible for the definition of the database structures as well as for the data stored in them and thus looks after the so-called persistence of the data. Every MES prod-uct possesses the data model corresponding to one version of a prodprod-uct.
Today this data model is normally stored in relational database systems and the corresponding data processed by means of SQL (structured query lan-guage).
The necessity of defining a data layer reveals itself in the overall view by the way products are mapped in the architecture of a modern MES system.
It can be seen from the diagram above that the products in an MES sys-tem are spread over three layers of the syssys-tem architecture. From this model a rule can be derived in the form that changes in or expansions of a product whenever possible take place only in one layer. This rule ensures stability and reduces the effort required to implement changes. The change itself takes place precisely in the layer which is responsible for the change.
Here the data layer handles the task of ensuring that the data for an MES product based on the underlying database system can not only be written reliably and permanently but also read again. The data layer defines the necessary tables and fields in the database system. All changes, modifica-tions and product expansions relating to the persistence of data will thus take place in this layer. Other examples of intervention in the data model
104 5 Building an MES system
are changeovers of database structures due, for example, to new function-alities or to a further system expansion into additional production areas or to cover additional applications. It is therefore clear that the data model often undergoes technical changes which conform only to a qualified ex-tent with the requirements made of the application.
This gives the user the ability to access the data layer directly via reporting tools in order to produce his own analyses in an elegant and simple manner.
Due to the changes we have described within the product, when the product is upgraded or when there are new versions of an MES product it frequently happens that the evaluation based on the data layer needs to be adapted to the modified data layer. From this it follows that direct accesses to the data layer cannot be classified as “release-proof”. Compatibility with future releases will not exist unless access to the data is via the application layer.
5.1.3 Application layer: business objects and methods
The application layer depends on the data layer and makes functionality available to the process mapping. The application layer covers the follow-ing important requirements:
The application layer provides the objects and corresponding methods for creating the business logic in the process mapping layer.
Fig. 5.2. Product image in the enterprise service architecture
5.1 Software architecture of an MES system 105 What is meant at this point by an object is, for example, “Machine 3523 with associated data” or “Operation 7330022 010 with associated data”.
A method means the functions by which the data of the object can be processed or functions which trigger actions for the object, such as log-ging someone onto a machine, for example.
The application layer supplies its objects and methods irrespective of the data model. This procedure ensures that if there are changes in the un-derlying data structures the application layer will look after the neces-sary compatibility and the objects and methods will behave in their normal way. In the case of new functions, the application layer will ex-plicitly make new objects and new methods available for them.
The demands made of the application layer show clearly that this layer has the important job of getting necessary technical modifications under control so that the process mapping can function as normal. Provided it has been correctly implemented, the architecture of an MES system will thus ensure that changes do not negatively impact already defined proc-esses.
5.1.4 Process mapping
The process mapping has the job of reproducing the actual business logic on the basis of the methods and objects of the application layer. One syno-nym for the term business logic is enterprise logic.
Via interfaces or graphical interfaces the process mapping receives mes-sages including the corresponding data which essentially are then proc-essed via “if-then” conditions and the use of the objects and methods of the application layer. The process mapping thus contains the actual logic of an application or of a product and in addition makes use of the underlying layers. One important characteristic of the process mapping is that the ob-jects and methods of all products are at its disposal. This means that sev-eral products can be “woven” together in the process mapping without any problem, something monolithic products do not permit.
This advantage becomes considerably greater if further products are to be added at a later date. If necessary, the methods of the new products will simply be incorporated into the existing process mappings. It should now be clear that these possibilities permit complete horizontal integration and interweaving of the applications, something which can also be carried out gradually.
A further advantage of the process mapping is the high degree of compati-bility with future application releases which this layer provides. The under-lying layers ensure compatibility in the event of revisions and modifications
106 5 Building an MES system
such as product upgrades, for example, so that the process mapping created is not affected.
For the if-then relationships, the classic configuration settings can be used as before. These are supplied to the process mapping from the appli-cation layer by means of the corresponding methods. The if-then condi-tions we have mentioned can, however, also be represented graphically:
the result is the so-called workflows. The advantage of a graphical repre-sentation is that on the one hand these workflows offer clarity and describe process flows in a readily comprehensible manner while on the other hand there is also the possibility of creating these workflows in electronic form and then generating the process mapping from them.
5.1.5 The advantages of ESA architecture for MES systems In systems without an architecture of this kind, changes in the processes and process sequences of the user often mean immense trouble and costs within the software being used since considerable intervention in the stan-dard processing routines is required, particularly in the case of product-independent changes. The architecture we have described of an MES sys-tem can, when used correctly and consistently, guarantee considerable re-ductions in costs and a faster implementation. In the most favorable case all that is needed is an intervention in the “process mapping” – in other words, the standard products being used need no modifications.
Other advantages of an ESA architecture for MES systems:
The limits of classic configuration methods disappear with the ESA architecture and new possibilities such as graphical workflow deliver clarity, transparency and security.
A complete horizontal integration is realistic and expenses are much lower than before.
It is now a good deal easier to introduce the solution gradually.
Processes can be mapped in the form of graphical workflows.
It is much easier to modify the process sequences than is the case with monolithic products, even after the introduction phase.
The risk of new errors creeping into existing process sequences is re-duced.
Changing products involves less effort.
There is a reduction in test phases and testing expenses.
Partners or even IT-savvy customers are potentially able to create equivalent products or modules at the MES supplier.
5.2 Interfaces of an MES system 107