Manufacturing Data Model

Author: Ralf Banning, May 2020

Since decades a suitable manufacturing model for industries has been discussed in the scientific community (see literature list) and has led to various international standards like STEP and PSL. Despite of this efforts, no general and 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 operations and today's systems 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 later on. This also shows that giving objects a name - the ontology of objects - depends on the context of usage. Keeping this in mind, the FlexFactory manufacturing (data) model is designed to meet the following objectives:

• use manufacturing related terms for 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 mgtt 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 ERSPRIT 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 entities marked in yellow will hold master data, whereas the others are considered to store transaction data.

• The routing contains an abstract definition of the steps (or tasks) performed during the manufacturing process for each material (product) an each disposition level
• The task entity contains a link to the operation which has to be performed (e. g. drilling, coating) and a specification (drilling at position x/y/z with diameter d and drilling depth s) of details of this operation.
  
• The partlist (optional) will declare a detailed list of materials, which are needed for a specific operation, or will consumed (e. g. drilling liquid), or will be result of this operation.
• The operation entity (on site level) will only be a repository, stating all serviced operations throughout this site.
• And finally, the material provides a reduced list of materials known for manufacturing (on this site).

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 ER 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 (routing and material) on 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 on area!
• If the sfcu should be handled as a lot or batch the corresponding data is stored in the plan entity.
• The current state of the tasks is stored in the taskcell entity, the current state of the sfcu is stored in the sfcu entity

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

• The area requests to take over the tasks for an sfcu by an TaskReq message.
• Every cell in this area which is ready (or able) to take over the task, will respond to this request sending a TaskBid message.
• The area (or a responsible) will select appropriate cells and assign the task by sending a TaskOrd message to the respective cell.
• This communication and the current state information for each task is stored in the taskstation entity.

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 lebvel)
• Store transportation request, route or status
• Store Bill of Materials (BOM) data
• Store Warehouse information and transactions

Finally, the next diagram shows the detailed data structure of the three model level (click on diagram will enlarge):

Site level data

Area level data

Cell and station level data

All entites shown on the diagrams above are instatiated as 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.

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.