Model

• 1: Characteristic Models
• 2: Common Descriptors
• 3: Event and Interaction Models
• 4: Intervention Models
• 5: Measurement Models
• 6: Production System Models
• 7: State Models
• 8: Worker Models

Clawdite’s reference model describes a HDT including human-centred elements but also contextual elements, relevant to characterise the workers and the surrounding environment in a production system. The model and its implementation aim at releasing an extensible, scalable and adaptable HDT. The advantage for the adopters of the proposed HDT model is two-fold: they can rely on a model built on the robustness of a scientific result; they are provided with ready-made packages of entities to instantiate their own HDT, by including also human-centred aspects (e.g., interactions, events), and software-based simulations/predictions (e.g., output of functional models predicting the state of factory entities).

There are 3 main types of data which are managed in Clawdite: measurements (dynamic data), characteristic (quasi-static data) and states (the output of functional modules).

Main elements

• Descriptor Elements (white, red, purple and blue boxes): contains the description and definition of all the HDT entities, and could be characterized by unit of measures, scales, category and taxonomies.
• Factory Elements (yellow boxes): The factory and its components are described by a hierarchical structure. The worker has a dedicated representation for enabling processing in the functional modules.
• Relationship Elements (green and orange boxes): events, interactions, interventions and exemptions describe the relationship between factory entities or workers.
• State Elements (sky blue boxes): Functional modules, based on the HDT knowledge, compute and provide insights related to factory entities and workers according to the defined block format.

1 - Characteristic Models

This set of classes allows to define quasi-static and static data describing workers and factory things.

Note that the required model attributes are indicated with a red asterisk ("*"). For mandatory relations, refer to the multiplicity instead, as relationships are defined on one side only (i.e., a specific relationship might be described within the other related entity).

CharacteristicDescriptor

The CharacteristicDescriptor allows the extension of AbstractDescriptor with a specific class dedicated to (quasi-)static data. The class can include any kind of characteristics relevant for the description of workers and other entities in the factory. For example, the height or the set of skills may be workers’ features modelled through the class CharacteristicDescriptor.

CharacteristicValue

The class CharacteristicValue allows the definition of the value that characterise a CharacteristicDescriptor of a specific factory entity, represented by the classFactoryEntity.

The CharacteristicValue is described by the following attributes:

The CharacteristicValue has the following relations:

2 - Common Descriptors

The classes belonging to the Common Descriptors allow the description of properties, characteristics, measurements, dimensions and states of the many entities operating in a factory, including workers, machines, robots and devices.

Note that the required model attributes are indicated with a red asterisk ("*"). For mandatory relations, refer to the multiplicity instead, as relationships are defined on one side only (i.e., a specific relationship might be described within the other related entity).

AbstractDescriptor

The AbstractDescriptor allows the description of any type of data managed by the HDT: characteristics, measurements and states. The descriptor can be enriched with different information such as its UnitOfMeasure, Category, TaxonomyItem and Scale. Thanks to these auxiliary classes, the AbstractDescriptor(s) can be of different nature, depending on the factory thing they describe.

The AbstractDescriptor is described by the following attributes:

The AbstractDescriptor has the following relations:

An AbstractDescriptor can be specialized into:

• CharacteristicDescriptor: it describes static or quasi-static data characterising entities in a factory (e.g., workers, robots). Examples of characteristics for workers are: a skill, an anthropometric characteristic, a job position. Examples of characteristics for machines are: weight, dimension.

• StateDescriptor: it describes the state of entities in a factory. For example, in the case of a worker, possible states are the current task, the next task to perform, the level of perceived fatigue, the current production performance.

• MeasurementDescriptor: it describes a measurement collected from a sensor (usually onboarded on a device), which refers to a factory entity. For example, in the case of a worker, a MeasurementDescriptor can describe the heart rate, measured by a wearable device.

UnitOfMeasure

The class UnitOfMeasure has been defined to facilitate the handling of the units of measure, which can refer to all the AbstractDescriptor(s) (i.e., CharacteristicDescriptor(s), StateDescriptor(s), and MeasurementDescriptor(s)). This class allows the definition of a unit of measurement.

The UnitOfMeasure is described by the following attributes:

Category

The class Category describes an AbstractDescriptor by means of an enumeration. For example, it can be "Anthropometric Characteristic", "Ability", "Skill", etc. It facilitates the organization and structuring of AbstractDescriptor(s).

The Category is described by the following attributes:

The Category has the following relations:

Taxonomy and TaxonomyItem

The Taxonomy class is used to classify an AbstractDescriptor accordingly with a taxonomy (either a well-know taxonomy, like (e.g., O*Net or ESCO for working skills, or a private one , e.g., a taxonomy that organises the roles in the company).

The Taxonomy is described by the following attributes:

The Taxonomy has the following relations:

A Taxonomy is composed by a set of TaxonomyItem(s), which represent the single items that compose a taxonomy (e.g., for the skills taxonomy, each TaxonomyItem represents a skill; in the case of the O*Net taxonomy, “Operation Monitoring”, “Quality Control Analysis”, and “Reading Comprehension” are TaxonomyItems).

The TaxonomyItem is described by the following attributes:

The TaxonomyItem has the following relations:

Scale

The Scale class is used to provide an AbstractDescriptor with a scale that narrows its possible values, making it easier to assign, understand, and interpret the measured value in a meaningful way.

The Scale is described by the following attributes:

3 - Event and Interaction Models

This section contains classes that are relevant for defining interactions between entities in the factory.

Note that the required model attributes are indicated with a red asterisk ("*"). For mandatory relations, refer to the multiplicity instead, as relationships are defined on one side only (i.e., a specific relationship might be described within the other related entity).

EventDescriptor and InteractionDescriptor

The EventDescriptor class describes the events that change the HDT status, evolving any of its entities or attributes. An event is related to a single entity. Events involving multiple entities are represented through Interaction(s).

The EventDescriptor is described by the following attributes:

The EventDescriptor has the following relations:

The InteractionDescriptor class specifies the EventDescriptor, requiring the event being an interaction between two or more FactoryEntityModel(s) (e.g., a collision between a robot and a worker, a worker that loads a pallet on an AGV, etc.).

The InteractionDescriptor has the following relations:

For example, a InteractionDescriptor can be “Impact between cobot and worker”, which aggregate the FactoryEntityModel(s) “Assembly Worker” and “Cobot UR10”.

Event and Interaction

The Event class defines an event described by an EventDescriptor.

The Event is described by the following attributes:

The Event class has the following relations:

As per the EventDescriptor class, also the Event class is extended by the Interaction class, which requires the event to involve at least two FactoryEntity(s). Indeed, the Interaction class has the following relations:

4 - Intervention Models

This set of classes allows to describe interventions to orchestrate the production system and the things acting within it, optimising performance and/or increasing workers’ wellbeing.

Note that the required model attributes are indicated with a red asterisk ("*"). For mandatory relations, refer to the multiplicity instead, as relationships are defined on one side only (i.e., a specific relationship might be described within the other related entity).

InterventionDescriptor and Intervention

The class InterventionDescriptor allows the definition of interventions that can be triggered to orchestrate the production system and its entities (i.e. the tasks to perform). Examples of intervention descriptors are: to deliver a notification to the operator, to set-up and activate a robot part-program, to turn-on a tool or to adjust the speed of a spindle. Interventions could be fired by the FunctionalModule(s) in charge of decision-making, defining workers and the things of the factory to be triggered.

The InterventionDescriptor is described by the following attributes:

The InterventionDescriptor has the following relations:

The class Intervention describes a triggered and actuated intervention.

The Intervention is described by the following attributes:

The Intervention class has the following relations:

Exemption

The class Exemption allows to specify which FactoryEntity(ies) are exempted from a specific InterventionDescriptor (i.e. task). An Exemption is related to a single entity-task tuple, in order to specify
exemptions related to multiple entities for the same task, or to assign multiple task exemptions to the same entity, it is needed to create different Exemption(s).

The Exemption is described by the following attributes:

The Exemption has the following relations:

5 - Measurement Models

This set of classes allows describing measurements and data collected from workers and things in the factory.

Note that the required model attributes are indicated with a red asterisk ("*"). For mandatory relations, refer to the multiplicity instead, as relationships are defined on one side only (i.e., a specific relationship might be described within the other related entity).

MeasurementDescriptor

The MeasurementDescriptor extends the AbstractDescriptor with a specific class dedicated to dynamic data, streamed by wearable devices, sensors and PLCs. These can include any kind of relevant data collected from factory entities. For example, hearth rate, galvanic skin response, vibrations, accelerations, temperature could be modelled through the class MeasurementDescriptor.

The MeasurementDescriptor is composed by the following attributes:

6 - Production System Models

This set of classes allows the definition of entities acting in the factory and collecting measurements to feed the HDT.

Note that the required model attributes are indicated with a red asterisk ("*"). For mandatory relations, refer to the multiplicity instead, as relationships are defined on one side only (i.e., a specific relationship might be described within the other related entity).

FactoryEntityModel

The FactoryEntityModel class describes the digital counterpart of the entities populating and thus acting in the factories such as robots, machines, pallets, workers, etc. . Characteristics, states, measurements and interactions of such entity models have to be included in the HDT. It is important to remark that the FactoryEntityModel is a generic representation of a factory entity, not its specific instance. For example, a FactoryEntityModel could be “assembly operator” or “Cobot UR10”. Specific instances of these models can be described in the Worker class, in case of a worker, and in the FactoryEntity in case of any other type of entity.

The FactoryEntityModel is described by the following attributes:

The FactoryEntityModel has the following relations:

For example, a FactoryEntityModel could be Cobot UR10 which could be composed by the following AbstractDescriptor(s):

• CharactersticDescriptor: reach, number of joints, installation date, etc.
• StateDescriptor: availability, current end-effector, current task, next task to be performed, etc.
• MeasurementDescriptor: joints position, workbench vibration, etc.

FactoryEntityModelCategory

The FactoryEntityModelCategory specifies the category of a FactoryEntityModel. In this way, it is possible to organize FactoryEntityModel(s). For example, the FactoryEntityModel “wearable device” may be assigned to two different categories: “wrist band” and “chest band”.

The FactoryEntityModelCategory is described by the following attributes:

DeviceModel

The DeviceModel is used to describe any device that generates measurements, including sensors, machines and wearables. Exactly like the FactoryEntityModel, the DeviceModel is a generic description of a device (it is not a specific instance). The need for this class arises from the fact that device models (e.g., vibration sensor SW-420, Siemens Simatic S7-1200), including wearables (e.g. Garmin Instinct) collect measurements in different ways and with different data structures. The DeviceModel class allows a particular device model to be described, enabling the mapping of physical device outputs to one or more MeasurementDescriptor(s) or StateDescriptor(s) in the HDT, minimizing the overhead of connecting devices of the same model.

The DeviceModel is described by the following attributes:

The DeviceModel has the following relations:

OutputMap

The OutputMap maps a physical parameter measured by a device with the field described by a MeasurementDescriptor, making the descriptor independent from the device models. A DeviceModel can produce different types of measurements (e.g., heart rate, blood pressure, etc.). This measurement must be created and described in the HDT using MeasurementDescriptor(s) so that other components can interact with it. Therefore, the stream of a device data must be mapped and connected to a MeasurementDescriptor. Moreover, different DeviceModel(s) may feed the same MeasurementDescriptor. For example, two wearable device models (e.g., Garmin Instinct and Polar OH1), may provide the same measurement (e.g., hearth rate). However, a user wants to have a unique representation of that measurement in the HDT. Therefore, a unique MeasurementDescriptor is created in the HDT, and each wearable model has an OutputMap, mapping the different outputs of the wearables to the same MeasurementDescriptor.

The OutputMap is described by the following attributes:

The OutputMap has the following relations:

FactoryEntity

The FactoryEntity class allows the creation of instances of entities in a factory described through a FactoryEntityModel. The FactoryEntity is a specific entity that populates the factory.

The FactoryEntity is described by the following attributes:

The FactoryEntity has the following relations:

Factory

The Factory class allows the definition of a factory where the FactoryEntity(s) act and operate, being able to have HDT representing entities in different production systems.

The Factory is described by the following attributes:

Session

The Session class allows data collection or working sessions to be defined; in such a way, the HDT tracks exactly when a particular FactoryEntity performs a specific activity, and to match Event(s), Interaction(s), and Intervention(s) with specific time slots.

The Session is composed by the following attributes:

The Session has the following relations:

7 - State Models

This set of classes aims at describing states characterizing factory entities. States are computed by functional modules, which describe all those computational processes that can elaborate entities and attributes, making the HDT capable of simulating, predicting, reasoning, and deciding. The class FunctionalModule aggregates one or more events that can be used to update the state of the HDT depending on the result of the computation performed. Inputs are defined and mapped through the class FunctionalModuleInput to the entities needed by the model (e.g., physiological parameters and worker conditions for detecting fatigue level). Internally, functional models can employ any mean of data processing and calculation such as mathematical functions, machine learning, or empirical models. These, if necessary, can be stored as binary blobs and annotated to be managed correctly.

Note that the required model attributes are indicated with a red asterisk ("*"). For mandatory relations, refer to the multiplicity instead, as relationships are defined on one side only (i.e., a specific relationship might be described within the other related entity).

StateDescriptor

The StateDescriptor extends the AbstractDescriptor with a specific class dedicated to the description of states of both workers and things in the factory. These states are computed by the FunctionalModule(s). The StateDescriptor can describe the state of a cobot in the form of the current pose, current part program, or the position or the fatigue level of a worker.

The StateDescriptor has the following relations:

FunctionalModule

The FunctionalModule class allows to describe any model that generates states. A model could be an AI algorithm or a simple data processor. The FunctionalModule defines a model that acts in the HDT and produces outputs that feed the HDT state. An example of FunctionalModule is the Fatigue Monitoring System or an Activity Detection Module.

The FunctionalModule is described by the following attributes:

The FunctionalModule has the following relations:

FunctionalModuleInput

The FunctionaModelInput supports the mapping that relates an AbstractDescriptor modelled into the HDT to an input that feeds the FunctionalModule. It allows the HDT to integrate modules that require input data with different structures than those described by MeasurementDescriptor(s), CharacteristicDescriptor(s) and StateDescriptor(s).

The FunctionalModule is described by the following attributes:

FunctionalModuleOutput

The FunctionalModulOutput supports the mapping that relates the outputs of a FunctionalModule and the related StateDescriptor(s) into the HDT. It allows the HDT to integrate modules that provide output data with different structures than those described as a StateDescriptor.

The FunctionalModule is described by the following attributes:

Block

The Block class is a utility entity that enables the formalization of the schema that describes the StateDescriptor(s), thus allowing the HDT to be aware of the data format. This helps FunctionalModule’s output validation against the schema, and also to translate/map an output schema of a module to an input schema of another module.

The Block structure describes every object's schema which contains coherent lists (a list that comprises elements of the same kind). For example, the location of different workers could be represented as follow (for simplicity the JSON format is used):

{
  "id": 10,
  "workers": [
    {"id": 10, "x": 10, "y": 20, "pose": "stand"},
    {"id": 20, "x": 23, "y": 40, "pose": "sit"},
    {"id": 30, "x": 10, "y": 20, "pose": "lying down"}
  ]
}

This example of output could be easily described through the use of the Block class:

• StructBased workerBlock:
  • “id” → NumberBased
  • “x” → NumberBased
  • “y” → NumberBased
  • “pose” → StringBased
• ListBased workersListBlock describe a list of workerBlock:
• StructBased overallBlock describes the whole object as it follows:
  • “id” → NumberBased
  • “workers” → workersListBlock

ListBased

The ListBased class inherits from Block and describes a list that contains elements structured as a Block, enabling the definition of a coherent list that comprises data of the same type.

StructBased

The StructBased class inherits from Block and describes a structure of Block(s). It can be seen as a dictionary with string keys and Block values.

The StructBased is described by the following attributes:

StringBased

The StringBased block describes a simple attribute of type string, which can be part of a StructBased or ListBased.

NumberBased

The NumberBased block describes a simple numerical attribute, which can be part of a StructBased or ListBased.

BooleanBased

The BooleanBased block describes a simple bo attribute, which can be part of a StructBased or ListBased.

8 - Worker Models

This section contains classes that are relevant for defining worker instances.

Worker

The class Worker allows the definition of worker instances. This class is used to represent a specific worker in the production system.

As of today, the class just inherits its parent’s properties and relationships, but it’s worth be noted that having a dedicated class enables a fine-grained management of the HDT entities by the HDT user. For example, measurements related to workers may require additional data preserving rules (e.g., when collecting biometrics data); moreover, workers can be “anonymized” within the HDT (e.g., the referenceCode may be missing or an anonymous code), while this operation is meaningless for other factory entities in almost all the cases. Moreover, the behaviour of factory entities is in general predictable with well-established models, while the behaviour of workers may be unpredictable (due to non-measurable features, like emotions), and this point plays a crucial role in an HDT. For this reason, it is important to distinguish workers from other nonhuman factory entities.