## 3 Framework Description
### Process Definition  
We define an industrial process as a group of interrelated high-level tasks, with each one comprised of interrelated subtasks. This definition is intended to be general for all kinds of processes, including the ones for processes and discrete manufacturing. For instance, consider a scenario where a worker is assembling a certain product and a robot is used to bring a new box of screws from storage five meters away once the previous box is empty. In this scenario, a task would be a high-level operation such as \"replace an empty box of screws\". Figure 1: Framework scheme. This task is divided into several subtasks: \"grab the empty box\", \"go to the storage area\", \"find a place to place the empty box\", \"leave the empty box\", \"find a box with screws\", \"grab the box of screws\", \"go to the working area\", and \"leave the new box of screws\". The granularity of the tasks depends on the needs of the simulation to be modeled. The structure of a task contains an information field, dependencies, and subtasks. The information field defines its general purpose, such as, for example, \"replace an empty box of screws\". This serves as a general description of the set of subtasks that involves changing the empty box for a new one. The dependencies are the set of tasks that need to be completed before the task begins. At any given time, a task can depend on the finalization of one or more tasks and it may be executed in parallel with other independent tasks. These dependencies may be modelled as a hierarchical structure of the tasks and subtasks that define a process. This structure is an extension of the assembly models presented [32; 33], since our subtasks are not restricted to assembly actions of parts. Each subtask consists of an information field, its dependencies, a mode, atomic actions, and goals. The information field allows for guiding the users while performing the subtasks and providing feedback when the task is being completed by an automated system (i.e., a robot, an AGV, or another system). This information is stored as a message that has a type (info or error) and a localized description of the error. As in the case of the tasks, the dependencies of a subtask are other subtasks that need to be completed before it starts. These are the implicit pre-conditions of the subtask. The mode defines the automation level of the subtask. We define two different levels of automation: _manual_ and _auto_. In _manual_ mode, the human worker manually performs a subtask. While in _auto_ mode, the system automatically executes a subtask using one of the predefined actors (such as a robot or machine). This mode allows for an optional fast-forward feature that performs a virtual simulation to complete the automatic operations instantaneously (this mode is helpful when the user needs to reach a certain point in the simulation while avoiding waiting for the entire completion of the operations). To define the action of a subtask, we used a simplified version of the language defined in [35; 36]. Each action requires an actor, which may be human or an automated system, which is in charge of executing the action. The actor is identified using an ID, which will be later used by the interface to map it within the simulator. A set of parameters are used to model targets, tools, and operation configuration. The goals of a subtask are the conditions that need to be satisfied to consider the subtask as completed. When a subtask is completed, it triggers an event to change its global condition. The global condition triggers another event to notify all the subtasks that depend on it of its new value. In this way, other subtasks can begin if their conditions are met. This process is the core of the sequential model of the proposed framework. Based on the previous definitions, we define a data model comprised by six classes: process, task, subtask, action, goal, and message (see Figure 2). This model defines:  
* A process that is composed of one or more tasks.