Manufacturing Data Model

Author: Ralf Banning, May and June 2020

Version: 2020-06-25

Since decades a suitable manufacturing model for industries has been discussed in the scientific community (see literature list) and was described in various international standards like STEP and PSL. Despite these efforts, no general or generally agreed meta-data model for manufacturing can be found in practice to day. Even looking deeply in to widespread IT-systems like SAP ERP or SAP ME, an archeology-like stratification of terms and definitions will emerge. It seems as if it has to be accepted, that in real-life we have to work with a broad variety of terms and data models. So, for example,  the part of the engineers, might be the material of the production planners, and the same object will be sold as product by the sales department finally. This also shows that giving objects a name - the ontology of objects - depends on the context of their usage.

An other major issue shows up when we consider non-tightly-integrated information systems like in the FlexFactory case, where many of the communication have to be promoted via network and "flat-structured" messaging protocols. As it shows up, the classical ERP-like data model with separated data entities for demand planning (i. e. BOM) and production planning (i. e. routing) does not really fit: the routing lacks task related information on material in- and output, the BOM does not reflect the time and resource structure. By a remark in Kurbel (2013, p. 65), Helmut Kernler proposed a so called "Resource List" structure to overcome similar problems (see Kernler, 1995), which is also used in today's SAP Supply Chain Management (SCM) systems and is known as "Product Data Structure" (PDS). Therefore, in our manufacturing data model we will use a master data structure which implements Kernlers Resource List in a similar way SAP did it with SAP SCM (for more details see elsewere TBD).

Keeping this in mind, the FlexFactory manufacturing data model is designed to meet the following objectives:

• use manufacturing related (domain-specific) terms for system objects
• use short and simple names for attributes
• provide a transparent transformation of terms from business domain to the domain of manufacturing
  

The second objective is also driven by the fact, that the different layers of the FlexFactory model (site, area and cell) are only interconnected by the light-weight messaging protocol MQTT, and therefore the JSON-format payload of MQTT messages will be more "readable" for humans by using clear and short attribute names. The "layers" mentioned before, are related to models as discussed e. g. by Molina and Bell (1999), dating back to the ESPRIT Project 932 factory model. Based on the first three levels (Factory = site, Shop = area and Cell = cell) the basic data structure for FlexFactory is defined as follows (click on diagram will enlarge):

The FlexFactory site-area-cell-model maps to this structure in following simple way:

• site → Factory
• area → Shop (Area)
• cell → Cell
• station → Station

Overview on Data Model and Process

Processing

The basic idea of processing the data is:

• Orders for manufacturing will be received from an external system (like customer orders, or interface to an SAP ERP system providing IDocs).
• When such an order is received, the relevant data will be stored in the order entity. To be able to process the order, the order data have to match the stored master data (pds and material) at the factory (site) level.
• After quality check of data and planning an optimization (not shown in the model so far!) the order will be released to the shop (one or more areas).
• With this release, the order is split into shop floor control units (sfcu, one per item) and the data is transferred to the assigned area(s). In most cases a typical FlexFactory setup will only comprise one area!

Having assigned the responsible manufacturing area, the next level processing follows these steps:

• The area requests to take over the tasks for an sfcu by an rfq message.
• Every cell in this area which is ready (or able) to take over the task, will respond to this request sending a offer message.
• The area (or a responsible) will select appropriate cells and assign the task by sending a asgmt message to the respective cell.

Data Model

The entities marked in yellow will hold master or template data, whereas the others are considered to store transaction data. Master data and templates serve as "copy template" data when rolling out production plans or task requests . All instantiation data (a.k.a. as transaction data) will be stored at the level where it is instantiated and published to lower levels afterwards ("downstream"). This "duplication" of data is motivated by the fact, that FlexFactory operates as an didactic system which makes every step in data communication transparent and persistent. This will allow detailed analysis on every level.

Multi site operation - impact on data model

(New in revision 25th of June 2020)

The proposal for Flexfactory implies that it should be possible to run areas and cells within different sites or areas. Since every component runs it's own persistent operational database and every object id (like order numbers and sfcu id's) is only unique at the site from which the data originates, primary key conflicts may occur, if a component is used within a different site. This is illustrated by the following diagram (click on, to switch page one and two):

Following Design Decision DD_17  including "namespace" or "origin" of transactional data object in the primary key of this objects will provide a solution. It seems to be natural in the context of manufacturing to choose the "site" as this namespace identifier, i.e. every table which may be used in a different context have to implement this "site"-column.

Notes: the solution is similar to the data separation in "client" aware business information systems like SAP ERP, where the Primary Key column MANDT (as German "Mandant") separates data from different clients. Whereas this client separation approach aims to allow a user only to see data of one client at a time, the site Primary Key works as a namespace, which implies to deal with data of different site at a time. As a Use Case consider an area of cells which offers operations to varying sites.

Site Level Data

• The pds is the header of the Product Data Structure and contains the relation to material to be produced,
  
• The pds_task entity contains a link to the operation which has to be performed (e. g. drilling, coating) and a parametrization (e.g. color, drilling diameter).
• The pds_part will declare details of consumed and produced materials ("in", "out") for each task.
• The pds_resource will provide information on required resources (like specific machines) and estimated production times. This may be used as well for planning as for routing within FlexFactory.
• The operation entity (on site level) is a simple repository of all serviced operations throughout this site.
• And finally, the material provides a reduced list of materials known for manufacturing (on this site).

Area Level Data

For the moment the area data model contains mainly interfacing data and rules the process of task allocation (to cells).

• The entities sfcu, order, order_task, order_part and order_resource are just instance copies of the site level and therefore have the same specification.
• After cell allocation (asgmt) the instantiation of this structure (sliced on operation dimension) is rolled out to the structure sfcu_task, sfcu_part and sfcu_resource. Specification is the same as with the corresponding tables.

Cell and Station Level Data

On cell level, which is also managing the station data, there is also some master data:

• The station entity contains a list of all stations in cell (normally just one!)
• The operation entity defines which operation a station (machine) provides, what is the specific setup time for this operation at this machine and so on.
• The consumption entity defines which production materials are consumed by an operation based on time or execution instance. Do not mix it up with material (parts) which will go into the product. Production material is also know as tertiary demand.
• The material entity on cell level is only used to store information on production materials

Obviously more entities will have to be defined with the project growing. The current model  lacks esp. the following abilities:

• Map transportation units to sfcu (to identify inbound material at station level)
• Store transportation request, route or status
• Store Bill of Materials (BOM) data
• Store Warehouse information and transactions

Implementation

All entities shown on the diagrams above are instantiated by the following SQLite database tables:

• site_db.db on Factory or site level
• area_db.db on Shop or area level
• cell_db.db installed for each cell, sharing data between the cell and the station on cell

Literature

Ayadi, M., Affonso, R. C., Cheutet, V. and Haddar, M. (2015) ‘Info Sim: Prototyping an information system for Digital Factory management’, Concurrent Engineering, vol. 23, no. 4, pp. 355–364.

Gelenbe, E. and Guennouni, H. (1991) ‘FLEXSIM: a flexible manufacturing system simulator’, European journal of operational research, vol. 53, no. 2, pp. 149–165.

Huang, H.-P. and Chang, P.-C. (1992) ‘Specification, modelling and control of a flexible manufacturing cell’, International Journal of Production Research, vol. 30, no. 11, pp. 2515–2543.

Kernler, H. (1995) PPS der 3. Generation: Grundlagen, Methoden, Anregungen, 3rd edn, Heidelberg, Hüthig.

Kurbel, K. (2013) Enterprise resource planning and supply chain management: Functions, business processes and software for manufacturing companies [Online], Dordrecht, Springer. Available at http://gbv.eblib.com/patron/FullRecord.aspx?p=1030480.

Leong, S., Lee, Y. T. and Riddick, F. (2006) ‘A core manufacturing simulation data information model for manufacturing applications’, Simulation Interoperability Workshop, Simulation Interoperability and Standards Organization, pp. 1–7.

Molina, A. and Bell, R. (1999) ‘A manufacturing model representation of a flexible manufacturing facility’, Proceedings of the Institution of Mechanical Engineers, Part B: Journal of Engineering Manufacture, vol. 213, no. 3, pp. 225–246.

Reynard, S., Gomis-Bellmunt, O., Sudrià-Andreu, A., Boix-Aragonès, O. and Benítez-Pina, I. (2008) ‘Flexible manufacturing cell SCADA system for educational purposes’, Computer Applications in Engineering Education, vol. 16, no. 1, pp. 21–30.

Spano, M. R., O’Grady, P. J. and Young, R. E. (1993) ‘The design of flexible manufacturing systems’, Computers in Industry, vol. 21, no. 2, pp. 185–198 [Online]. DOI: 10.1016/0166-3615(93)90135-N.

Zhao, J., Cheung, W. M. and Young, R.I.M. (1999) ‘A consistent manufacturing data model to support virtual enterprises’, International Journal of Agile Management Systems, vol. 1, no. 3, pp. 150–158.

Zhou, B.‐h., Wang, S.‐j. and Xi, L.‐f. (2005) ‘Data model design for manufacturing execution system’, Journal of Manufacturing Technology Management, vol. 16, no. 8, pp. 909–935.