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, it has to accepted that in real-life operations and today's systems we have to work with a broad variety of terms and data models. So 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 examples 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 follow a model as discussed by Molina and Bell (1999), dating back to ERSPRIT Project 932 factory model (own work):
Based on the first three levels (Factory = site, Shop = area and Cell = cell) the basic data structure is defined as follows:
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 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)
- The partlist (optional) will declare a detailed disposition level list of materials, which are needed for this operation, or will consumed (e. g. drilling liquid), or will be result of the operation.
- The operation (on this level) will only be a repository, stating all serviced operation throughout this site.
- and finally, the material provides a reduced list of materials known for manufacturing.
The basic idea of processing the data is:
- Orders for manufacturing will be received from external systems (like customer orders, or interfaces 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 al typical FlexFactory setup will only have on area!
- If the sfcu should be handled as a lot or batch the corresponding data ist stored in the plan entity.
- The current stat of 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 in a 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 cels and assign the task by sending a TaskOrd to the respective cell.
- This communication and current state of each task is stored in the taskstation entities.
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 are also know as tertiary demand.
- The material entity on cell 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 model: