Manufacturing Process Management System

Short name: MPMS

By TUE

Purpose

MPMS provides end-to-end (i.e., from order reception until product delivery) manufacturing process management and orchestration of activities by:

modeling processes and agents
executing in automated way the processes by assigning activities to agents
providing process monitoring for a complete status overview of the manufacturing processes

Data interfaces

Input and output data (but not user interfaces):

INPUT: Process, Task, Agent (and other related) definitions
- Format: DB data - Connection/Interfacing to a DB server. The core data model is shown below:
Note: Step data, which describes the detailed actions for executing a task (e.g. robot motions), is typically defined by a Local component. As such, MPMS does not use this info directly but it is important input data with respect to its connection to Task data.
- Real-time constraints: Stable internet connection
- Expected data volume:
INPUT: Process models requirements
- Format: Text
- Real-time constraints: N/A
- Expected data volume:
This information is derived from the requirement analysis and will be then modeled in the BPMN process models.
INPUT: Process models
- Format: BPMN files (raw format as XML)
- Real-time constraints: N/A
- Expected data volume: <1MB (a few KBs)
This is rather an “internal” input/output, since the Process Modeler module provides the files into the Process Engine module (both modules are part of MPMS).
INPUT: Events
- Format: JSON. A typical message syntax is the following:
```
{
    "messageName" : "New_ProcessEvent_arrived",
       "processInstanceId" : "2f3-7d-11e7-8d9-5c135",
       "processVariables" : 
       {
           "event_name" : {"value" : "aName", "type": "String"},
           "aProcessVariable" : {"value" : "aValue", "type": "String"}
       },
       "all": "false",
       "resultEnabled": "true"
}
```
  Notes: 1. Based on the event_name, the Process Engine of MPMS knows what to do. 2. The processInstanceId is the one generated by the Process Engine and has communicated to interested components, so these can send events to MPMS that refer to this specific process instance.
- Real-time constraints: Stable internet connection
- Expected data volume: < 1MB per message

INPUT: Task status

Format: JSON. There can be different types of syntax. Below two (working) suggestions:

{
'Topic': 'task_completed',
'ResponseMessageID': '20170620115843',
'SenderID': 'Local_Component_X’,
'Receivers':'MPMS',
'Type': 'notification',
'Timestamp': '20200620120854',
'Body': {
         'EventID': '', 'Details': 
                         {
                         'task_id': '30', 'task_instance_id': '40v-a5-11e7-81c4-289', 'process_instance_id': 'b60-511e7-be1e-f53 '}, 
                         'Variables': 
                            {
                         	'defect': {'value':'wrong_design'}
                            }
         }
}

{

   "messageName" : "New_TaskEvent_arrived",
   "processInstanceId" : "e0d5-6f0e-1e8-99-553",
   "processVariables" : {
                "task_status" : {"value" : "completed", "type": "String"}, 
                "task_instance_id" : {"value" : "e0b7-6f0e-11e8-9c79-583", "type": "String"},
                "task_id" : {"value" : 11, "type": "Integer"},
                "task_variables" : {"value" : "{"a_string_variable":{\"value\":\"a_string_value\"},\"a_boolean_variable\":{\"value\":true},\"a_num_variable\":{\"value\":42}}", "type": "String"}
                },
   "all": "false",
   "resultEnabled": "true"
   }

Notes: The second example has the formal Camunda API syntax.

Real-time constraints: Internet connection
Expected data volume: < 1MB per message

INPUT: process status
- Format: Dashboard
- Real-time constraints: Stable internet connection
- Expected data volume:
  
  Notes: The default “process status”-oriented dashborad visualizes data taken from the Process Engine. In case other type of visualization is preferred (e.g. a dashboard with a “physical layout” orientation), this new dashboard should retrieve information both from Process Engine and the DB which has any related information (e.g. agent, product, sensors, etc. data).
OUTPUT: Process, Task, Agent (and other related) definitions
- Format: DB data - Connection/Interfacing to a DB server.
- Real-time constraints Stable internet connection
- Expected data volume:
  
  Note: The population of data for the definitions of the aforementioned entities is done mostly manually (i.e., no module/UI to provide these as output).
OUTPUT: Process models
- Format: BPMN files (raw format as XML)
- Real-time constraints: N/A
- Expected data volume: <1MB (a few KBs)
  
  This is rather an “internal” input/output, since the Process Modeler module provides the files into the Process Engine module (both modules are part of MPMS).
OUTPUT: Events
- Format: JSON. A typical message syntax is the following:
```
   {
    "messageName" : "New_ProcessEvent_sent",
       "processInstanceId" : "2f3-7d-11e7-8d9-5c135",
       "processVariables" : 
       {
           "event_name" : {"value" : "aName", "type": "String"},
           "aProcessVariable" : {"value" : "aValue", "type": "String"}
       },
       "all": "false",
       "resultEnabled": "true"
   }
```
  Notes: 1. The information of the recepient is ommited in this message example (we can either add it or can be configured with code outside the message, e.g. when all events go to an event broker) 2. Based on the event_name, the recepient should know what to do 3. The processInstanceId is generated by the Process Engine and in case the recepient needs to react on this event for that specific process instance should include it on the message to MPMS (see INPUT: Events)
- Real-time constraints: Stable internet connection
- Expected data volume: < 1MB per message

OUTPUT: Task assignments

Format: JSON. There can be different types of syntax. Below two (working) suggestions:

  {
       'Topic': 'task_completed',
       'ResponseMessageID': '20170620115843',
       'SenderID': 'Local_Component_X’,
       'Receivers':'MPMS',
       'Type': 'notification',
       'Timestamp': '20200620120854',
       'Body': {
                'EventID': '', 'Details': 
                                {
                                'task_id': '30', 'task_instance_id': '40v-a5-11e7-81c4-289', 'process_instance_id': 'b60-511e7-be1e-f53 '}, 
                                'Variables': 
                                   {
                                  'defect': {'value':'wrong_design'}
                                   }
                }
  }   OR

      {
          "methodname": "task_assignment",
          "agent_id": "5",
          "task_id": "11",
          "task_instance_id": "7cf89-fb6e-11e7-8d69-5cb53",
          "process_instance_id": "81cf3-fb6d-11e7-8d69-5ca53",
          "task_variables": "{\"aVariableName\": \"aVariableValie\", \"aBooleanVariableName\" : false}"
      }    Notes: The *`taskInstanceId`* and *`processInstanceId`* are generated by the Process Engine and the recepient should include them on its messages to MPMS (see INPUT: Task status)

Real-time constraints: Internet connection
Expected data volume: < 1MB per message

OUTPUT: process status
- Format: Dashboard
- Real-time constraints: Stable internet connection
- Expected data volume:
  
  Notes: The default “process status”-oriented dashborad visualizes data taken from the Process Engine and is rather static, i.e., it does not offer any active output/functionality. In case other type of visualization is preferred (e.g. a dashboard with a “physical layout” orientation) in which a user or another system needs to interact, this new dashboard should provide the related data (the format TBD).

The input data will be taken from Component X of Partner Y and also from sensors available at Pilot Z. Please update. The output data will be pushed to Component X… or to system Y available at Pilot Z. Please update

See individual INPUT/OUTPUT data for interaction from/to other components/systems.

Communication in SHOP4CF

Documentation of communication among SHOP4CF components