1. Introduction

In the modern economy, organizations need to be more efficient and cost-effective to survive the ever-increasing competition. In other words, these organizations must develop, execute and manage their complex processes (such as order processing, purchasing, production and logistics or financial processes) keeping in mind the dynamic markets and the continuous changes that they face every now and then such as new customer needs or new government policies. Thus, it is crucial for the organizations to imbibe technologies and underlying information systems (IS) that support their need for flexibility and reuse. In this context, Process-Aware Information Systems (PAIS) have emerged as a promising solution to enable efficient "process-oriented" management and execution of complex processes involving both systems and people on the basis of specific process models. Most typical examples of these PAIS are the Workflow Management Systems (WfMSs) and the Business Process Management Systems (BPMSs). In fact, several real cases from the industry illustrate and ensure the advantages of imbibing these PAIS, which has helped different organizations such as Lufthansa, Siemens, Deutsche Bahn, Zalando SE, to name just a few, to achieve the desired business transformation so as to remain effective in today's dynamic business environment.

Business Process Management (BPM) is a field in operations management that is focused on improving the performance of an organization and the overall value generated by them through the optimization of their business processes (BPs). A process model also referred as a "Business Process Model" is the key component in BPM. It consists of various steps, i.e., activities (or tasks) and their execution order along with certain perspectives (behavioral or organizational) taking place in an organization over a range of time and at various locations. In literature, various process-modeling languages have been proposed, each having its own specific graphical representation but with the same underlying essence. The most notable examples of these modeling languages are: Business Process Model and Notation (BPMN), Event-driven Process Chain (EPC), XML Process Definition Language (XPDL), Petri Nets and Unified Modeling Language (UML) Activity Diagram (AD). Furthermore, to support continuous improvement of the BPs, the BPM lifecycle is mainly categorized into four phases that are, Process Design, Process Implementation, Process Execution and Process Diagnoses. In fact, the process design phase is the initial and a crucial phase in the BPM lifecycle. This is because the errors introduced in the design phase will propagate to other phases resulting in wastage of effort, time and resources, and finally requiring a re-design of the process model itself. Thus, it is critical to properly design the BP models based on the specified business requirements and to analyze them (i.e., validation and verification) along with performing simulations on them to check for the desired outcomes.

Today, various complex BPs having a "physical character" (i.e., interaction with the physical world) are executed either by a single organization or collaboratively by a set of autonomous organizations. Such processes can be found in several business domains such as supply chain and logistics (Industry 4.0), healthcare, smart home automation, to name just a few. For example, in case of an integrated supply chain and manufacturing networks, a network of companies providing transportation and administration services collaborate to enable the process of physically moving a container(s) (containing goods) from one geographical location to another. Both the containers and their contents (perishable or non-perishable goods) are the physical items to be managed along with the management of resources such as the vehicles (trucks, ships) and the robots that support the overall process. These processes rely heavily on the use of various heterogeneous devices (and their data) connected over the internet, which need to be orchestrated in a specific sequence to achieve the desired outcome. These connected devices form the Internet of Things (IoT) and based on their granularity can be broadly classified simply into Sensors, Actuators, and Tags (such as Radio Frequency Identification (RFID)) or simply into "things" such as robots (i.e., a specific combination of sensors, actuators and computation unit) and smart objects (i.e., object with embedded sensors, actuators or tags). They enable sensing, actuating (or reacting) and exchanging or collection of data through a communicating network such as the internet. Traditionally, in the BPM domain, the information about the event and processes occurring in the physical world are linked to the digital world via the data entered by the humans or via web services. These humans also assist in controlling the outcome of the physical world based on the data coming from the processes. However, with the use of IoT devices both the information about the physical world and the control over the physical world can be achieved instantaneously through the information systems. In fact, many such organizations rely heavily on the use of PAIS such as BPMS to efficiently manage their processes. Nonetheless, to optimally manage their allocated resources, i.e., both human and non-human (devices and systems), these PAIS need to become resource-aware} and further evolve into "Process- and IoT-Aware Information Systems". Thus, it is important to effectively model and manage the IoT resource allocations in the BPs so as to effectively orchestrate these IoT resources in BPs.

Despite growth in research on the integration of BPM domain (and underlying technologies) with IoT domain, still there exists several gaps and research challenges to foster the optimal allocation and management of IoT resources in BPs. In literature, the research work in the area of BPM has been more focused around the control-flow perspective with some works focusing on the resource perspective in BPs for the management of human resources. However, there has been a lack of work done towards tackling the specificity related to the IoT domain such as heterogeneity in BPs. In BPM domain certain research work have also proposed the use of semantic technology (Semantic Web) to enrich the process models with semantic annotations. These semantic approaches in BPM domain help to solve the problems related to heterogeneity in BP models due to the use of various modeling languages in an organization. They also enable the application of formal reasoning techniques in order to assist in discovery, composition, mediation, and execution of BPs. Such semantic technologies can also assist in formalizing the concepts and complex relationships from the IoT domain in the context of BPM domain.

Likewise, several works have proposed approaches to develop the IoT domain such as the EU FP7 project, “The Internet of Things Architecture” (IoT-A), which provided a reference architecture for IoT domain. Also, many other approaches have applied semantic technology to the IoT domain to tackle the problems related to heterogeneity of devices and proprietary data formats so as to promote interoperability such as the EU H2020 FIESTA-IoT project,which provided the FIESTA-IoT ontology along with a simplified semantic model so-called IoT-Lite. This model reused the concepts from the well known semantic model from W3C for sensor network such as the Semantic Sensor Network (SSN), to name just a few. However, to the best of our knowledge, there has been no uptake on realizing the integrating of the two domains of IoT and BPM.

In this work, our contribution addresses this research gap by proposing a semantic formalization of IoT resource perspective (including concepts and relationships) in BPs. Our approach is based on formalizing and integrating the IoT resource perspective in BP models and using semantic technology to enrich these processes. For this purpose, we develop a novel comprehensive cross-domain ontology called the "Internet of Things in Business Processes Ontology" (ThingsPrO). Overall, our approach does the following:

  • Provides an extension to the BPMN 2.0 meta-model for integrating the IoT resource perspective,
  • Provides a cross-domain semantic model that integrates the IoT concepts and their complex relationships with the concepts from the BPM domain,
  • Provides strategies for resolving resource-based conflicts,
  • Provides an ontology-based knowledge base that includes the information about the processes and the heterogeneous IoT resources. Being machine-readable, it assists in reasoning and discovering new relationships.

2. Motivating Example

In the real-world, many BPs imbibe certain physical characteristics. Such processes can be found in several domains such as logistics, healthcare, smart homes to name just a few. We motivate our work using examples from the supply chain and logistics domain. To keeps the examples sound, these process models are adapted from the literature, which were developed and used in the EU FP7 IoT-A project. The example in Figure 1 has been modeled in BPMN but it can be easily extended to other modeling languages such as EPC. Figure 1 represents a BP for monitoring the condition of goods in a supermarket or in a warehouse. An adaptation of the same monitoring process is applied to a container (logistics) transporting goods from one location to another via a truck or ship.

Overall, Figure 1 represents a self-triggering process (every 60 seconds) wherein an activity "a1" is used to measure the temperature of a physical object such as a Chinese Orchid flower. This temperature data is sent to the "Backend Application via activity "a2". While the temperature is within a pre-described range, the process ends without any alert. Otherwise, the activity "a3" raises an alarm message. The activity "a4" is used to estimates the degradation in the quality of the item based on some pre-described algorithm (out of the scope of this work) and this information is stored in a "Sensor Historical Datastore". If the estimated quality is within a pre-described range, the process ends without an alert. Otherwise, with the use of activity "a5", it checks for the temperature alarm message and reduces the price of the physical entity, i.e., Orchid. The activity "a5" sends a message to both: (1) the "Cashier System" that updates the price of the physical entity in the system via activity "a6", and (2) the "Electronic Shelf", having a Tag device, to update the price of the product stored on the RFID Tag via activity "a7". This monitoring process enables a supply chain to serve its customers in a better way by following a dynamic pricing mechanism based on real-time information from the sensor.

Figure 1: A BP model for monitoring temperature of orchids

The BP example in Figure 1 will need to integrate (or "glue") several IT systems and IoT devices together. Thus, before the actual implementation of this process takes place, all the underlying technical details related to the IoT devices (and other systems) must be included in the BP models.

During the actual deployment of the process depicted in Figure 1, the BP involves the use of information from IoT devices such as a sensor and RFID device to complete the tasks. Thus, the activity $a1$ will be associated with a sensor for instance "sensor1", while the activity "a" will be associated with an RFID Tag (for instance "RFID1"). Additionally, it is to be noted that these IoT resources participating in the process have specific features such as energy consumption cost, network usage cost and specific behaviors such as privacy (and shareability). For instance, an RFID resource can be associated with a single activity in a single process or multiple activities in different processes. While a sensor can be associated with a single activity, or it can share its data via a publish-subscribe middleware. However, the current state-of-the-art does not support such resource allocation that considers the integration of relevant IoT features. In addition, there is no support for a formal description of concepts from the IoT domain and their relationships with concepts of BPs.

Based on the EU FP7 IoT-A project, other important resource properties that characterize an IoT device are, "QuantityKind" that depicts the kind of physical quantity they measure (for e.g., temperature, light, humidity) or other quantities such as "BatteryLifetime", "ComputationCapacity", to name just a few. However, due to a plethora of heterogeneous IoT devices it is important to formally and explicitly define the characteristics of the IoT resources participating in a process. These characteristics must be included in the process during the design phase itself to tackle the challenges of heterogeneity for e.g., two devices measuring the same quantity such as, temperature, may have non-trivial differences in their capabilities such as, sensitivity or response time. In our work, we tackle these challenges w.r.t heterogeneous IoT resource during design phase by allocating them on the bases of our semantic model that allows to perform constraint verification for these resources so as to foster their efficient management.

3. Framework Description

In this contribution, we make use of the structured nature of BPs and integrate the IoT domain into it by including IoT specific concepts (and features) such as devices, network, energy cost, sensitivity, to name just a few. The concepts from the BPM domain, i.e., mainly a task (or activity) is extended to include the resource concept for allocating the IoT concepts that will participate in a process. Figure 2 represents the important concepts and their underlying properties that are present in the ThingsPrO semantic model. The naming convention followed to represent these concepts in Figure 2 are as follows: prefix "bpmo" represents the concepts from the BPMO namespace, the prefix "FiestaIoT" represents the concepts from the Fiesta-IoT namespace, and the prefix "thingspro" represents the concepts from the ThingsPrO namespace.

Ontology File and Documentation

The ontology developed in this work can be found here, i.e., ThingsPrO Ontology. This ontology reuses the concepts of FIESTA-IoT and BPMO ontology and also extends our earlier work so-called IoT-BPO, which uses the IoT-Lite and BPMO ontology.

To better illustrate the underlying concepts and classes, we also created a ontology documentation, i.e., OWLDoc, which represents the concepts in the ThingsPrO ontology. We developed this ontology and the documentation using the open-source Protégé tool from Stanford University.

3.1 Ontology Concepts

Figure 2 represents the concepts in ThingsPrO ontology, wherein the "bpmo:Task" concept is connected to the "thingspro:Resource" concept using the object property "allocate". There is another object property so-called "deAllocate" between the Task concept and the Resource concept. These properties represent the most important relationship between a Task concept reused from the BPMO ontology to a Resource concept developed in our ThingsPrO ontology. Figure 2 also depicts other concepts reused from both BPMO and FIESTA-IoT ontologies such as "Process", "workflowElement", "IoTDevice" etc. To clearly differentiate between the two main resources involved in a IoT-aware BP, i.e., human resources and IoT resources, the "thingspro:Resource" is modeled to contain two sub-concepts "thingspro:HumanResource" (representing the humans and their roles) and the "thingspro:Non-HumanResource" (representing the IoT device, network, and other enterprise applications). As mentioned earlier, this work is focused on the IoT resource perspective, which is represented via "thingspro:IoTResource" concept, thus we do not go into the details about the human resources.

The "FiestaIoT:Device" concept represents the various types of devices in the IoT domain (as per IoT-A reference model). This concept is further divided into three sub-types: (1) "FiestaIoT:SensingDevice", (2) "FiestaIoT:TagDevice", and (3) "FiestaIoT:ActuatingDevice". To support optimal IoT resource management and to avoid failure (or conflict) during the process execution phase, the analysts (model designers) must include the information related to all the IoT specific properties in the process models.

In Figure 2 , it is visible that the "thingspro:Resource" concept is linked to three main concepts that support the management of IoT resources. They are: "thingspro:ResourceType", "thingspro:ResourcePrivileges", and "thingspro:Constraint" concepts. The "thingspro:ResourceType" concept depicts the type of a resource, wherein a resource can be of one of the two types: (1) logical and (2) Physical. Logical, meaning that the consumption of the resource may lead to a decrease in its availability, e.g., storage space on a device. Physical, meaning that the consumption of the device does not lead to any decrease in its availability, e.g., the physical part of an RFID Tag device. The concept "thingspro:ResourcePrivileges" signifies that a resource has specific privileges or state regarding the execution of certain actions (allowed or not allowed). The concept "thingspro:Constraint" helps in marking various boundaries while allocating an IoT resource to an activity. For instance, let us take a simple but important constraint, wherein one activity can only be allocated to one type of IoT resource, i.e. the same activity cannot be allocated to a sensor and an actuator. These constraints (simple or complex) enables the process to behaves in the desired manner during the process execution phase. The "thingspro:Constraint" concept is closely related to "thingspro:Conflict" concept that depicts the actual conflicts that might occur during the process execution. These conflicts are handled by resolution strategies represented via "thingspro:Strategy" concept.

For a BP involving an IoT resource (or data), it is crucial to preserve the right balance between maximizing the QoI and minimizing energy cost. For instance, minimizing the device communication leads to minimization of its energy consumption. For modeling energy cost, we reuse and adapt the concept of AC introduced by Martinho et al. In Figure 2, we relate the concept "thingspro:costParameter" with the concept "FiestaIoT:Device" via object property "hasCost". It has four sub-classes, they are:

  • Class "thingspro:energyCost", which is related with "thingspro:processorEnergyCosts" and "thingspro:radioEnergyCost", i.e., the costs associated with the central processing units (CPUs) or with activation or maintenance of frequency-related electronic devices (radio emitters/receivers), respectively,
  • Class "thingspro:communicationCost", which depends on the concepts such as, "thingspro:bandwidth", "thingspro:latency" and "thingspro:radioRange" cost (higher cost for more extended range) that are involved for establishing communication within a specific device,
  • Class "thingspro:ActuationCost", which is associated with the cost of performing some actuation task,
  • Class "thingspro:virtualCost" (not visible in Figure 2), which is an abstract class whose concrete value depends on some actual cost (energy or communication cost). However, the resource provider can define any cost.
Furthermore, the "thingspro:costParameter" concept has two object properties: (1) "hasCostValue", which defines the value of the cost and, (2)"hasCostUnits", which defines its units.

Figure 2: Main concept in ThingsPrO ontology and their link to FIESTA-IoT and BPMO

3.2 Ontology Attributes

In our semantic model, an IoT device is depicted by the attributes where certain attributes are common to all the devices for e.g. IP address, while certain attributes are specific to each device type.

For instance, the "FiestaIoT:sensingDevice" concept has specific attributes such as energy cost, response time and latency. Likewise, the "FiestaIoT:actuatingDevice" concept has attributes like speed and force (static force and dynamic force). The "FiestaIoT:TagDevice" concept will have specific attributes such as storage capacity, device type to name a few.

3.3 IoT Resource Properties and Relations

These IoT specific properties are very relevant during the modeling and development of IoT-aware BPs and must be included in the process models so that they can assist the IT operations teams during the process implementation phase. This is because if ignored then each of these IoT specific features may lead to process failures during the process execution phase. Thus, it is crucial to model all relevant IoT properties during the process design phase.

For instance, an IoT device is associated with a specific energy-related cost parameter represented by "thingspro:costParameter", wherein the concept such as the "thingspro:energyCost" and the concept "thingspro: communicationCost" must be modeled as they have impact on the overall SLA of the BP. Furthermore, as visible in Figure 2, there are several other characteristics (capabilities) of a IoT device (or the concept "FiestaIoT:Device") represented via concept "thingspro:capability and its sub-concepts. They are: (1) "thingspro:shareable", (2) "thingspro:limited" and (3) "thingspro:QualityOfInformation".

Type of Property Description
Shareable

At any given time, an IoT resource (and its data) must be associated and simultaneously used by at least two or more tasks (or activities) from the same process or from different processes.
Non-Shareable

At any given time, the resource can only be used by one task in a process.
High Access Cost (HAC)

The IoT resources in this classification have high energy-related cost such as high power consumption. Some of these devices need to be connected to the main power supply rather than to battery power. Such devices tend to have low latency during communication and are "always-on" involving a high energy cost for communication with the network.
Low Access Cost (LAC)

These IoT resources have low energy-related cost and lower power consumption. They are mostly battery operated and the latency involved in such resources is higher with reduced number of communication with the network.
Limited

In these IoT resources, there exists a maximum limit that has a direct effect on their usage or resource capability such as computation limit, storage limit, battery lifetime. Thus, once the devices reach these limits, the resources are no longer available for usage.
Non-Limited

These IoT resources have no maximum limit for their usage and they can provide a specific capability for longer periods. For instance, a passive RFID Tags (in cards, clothes etc) have no energy limitation as they do not use internal power source.
Table 1: IoT Resource Properties in BPs

IoT resources take part in a process by being associated to a task to perform some actions (sensing or actuating). These resources have special relationships that should be formalized to ensure efficient resource management. These relation are described in the Table 2.

Relation Type Relation Name Description
IoT Resources Aggregation(ri, rj) ri and rj are of same type and both are allocated to the same task. They provide a composition of services
Replacement(ri, rj) rj substitutes ri, if ri is unexpectedly unavailable
Hybrid Resource Dependency Integration(ri, si) IoT resource ri provides a service that is composed with non-IoT service si
Hybrid Resource Dependency with Human Resources Substitution(hi, ri) It represents that a human resource (hi) can substitute a IoT device ( ri) in case of unavailability.
Table 2: Relationships between IoT and other resources

3.4 IoT Resource Conflict Resolution

To ensure optimal resource management, we define constrains on the resources to be mapped to a task during the design phase. These constrains are expressed in terms of SWRL formalization and can be defined on both the resource property and resource relations. In case of any constraint violation, a process may fail due to conflicts caused by them.

In our framework, we address these Conflicts (related to resources constraints) through a Strategy that consists of actions. We specify semantic rules following the (E)vent-(C)ondition-(A)ction structure (On Event If Conditions Do Actions), wherein events represent conflicts and conditions denote constraints. Actions suggests the set of solutions to take for resolving a conflict (Strategy). We use SWRL to formally describe one example of such ECA-based conflict resolution strategies and explain it as follows:

Strategy Name Event/Conflict Conditions/Constraints Action/SWRL Strategy
SThingsPrO1 Task(?t1) ^ Sensor(?sensor1) ^ allocate(?t1;?sensor1)
^ hasResState(?sensor1;?rs) ^ swrlb : equal(?rs;“unavailable”)		 Sensor(?sensor1) ^ Sensor(?sensor2) ^ Quantity(?qType)
^ swrlb :equal(?qType;“temperature”) ^ hasQuantityKind(?sensor1;?qType)
^ hasQuantityKind(?sensor2;?qType) ^ replacement(?sensor1;?sensor2)		 Task(?t1) ^ Sensor(?sensor1)
^ Sensor(?sensor2) ^ deAllocate(?t1;sensor1)
^ allocate(?t1;?sensor2)
Table 3: SWRL based strategies for conflict resolution

4. Validation

4.1 Ontology Coverage Validation

Since our work is aimed to semantically represent and share IoT resources, we compare the IoT-A reference model to the concepts that we covered in ThingsPrO (comparing the ontology to a golden standard). Thus, as presented in Table 4, we covered all important IoT-A concepts.

Specifications Classes Quantity Coverage Ratio
IoT-A Physical Entity, Device, Actuator,Sensor, Tag, Service,
Virtual Entity, Augmented Entity, Resource,
Network Resource, On-Device Resource,
Digital Artefact, Active Digital Artefact, Passive Digital Artefact, User, Human User		 16 16 100%
Table 4: ThingsPrO coverage of concepts in IoT-A reference model

We also compared the coverage of our semantic model with the other state-of-the-art ontologies and the details can be seen in our Journal Article or in the PhD thesis manuscript.

4.2 Proof of Concept

To validate our framework, we extended the web-based open-source version of the Signavio process editor, which is a powerful tool for mastering process management, with a semantic layer implementing our semantic framework (the commercial web-site for Signavio BPM).

The plugin takes as input a selected activity from a BPMN process with the aim to attach a resource that it consumes. Then, a mapping with the ThingsPrO ontology is realized and the business process model is annotated with the set of consumed resources, thus generating an enriched model as an output. Resources are described with attributes, properties and (if exist) its relations with another resources

4.2.1 Integration of IoT Resource Definitions

In this work, the BPMN 2.0 semantics is extended to include different IoT resources, i.e., Sensor Device, Actuator Device, and Tag Device, along with network resource. The extended BPMN 2.0 semantics supports the inclusion of the properties of these devices such as energy cost, IP address, accuracy, response time etc.

During the process design-time, analysts can drag and drop the relevant IoT resources from the shape repository into the modeling canvas (i.e. from the extended version of Signavio). Then these resources are associated with the appropriate task (see area 1 in Figure 3). The resource properties can be updated to include the characteristics of the IoT resources. The serialized BPMN 2.0 models (in BPMN 2.0 XML) created using our prototype tool contains both the IoT semantics and the diagram-interchange information about the IoT resources and their association with the activities/tasks in a process model.

4.2.2 Semantic Description Using ThingsPrO

Here, we briefly detail the work related to the semantic layer. This layer supports to annotate (associate) a selected activity from the BPMN 2.0 process model with an IoT resource concept, so as to generate an enriched model as output. IoT resources are described with attributes, properties and their relations (if any exists) as shown in Figure 1. In other words, this tool supports the users to map the relevant IoT concepts provided in ThingsPrO ontology to the activities in the modeling canvas.

The ontology is expanded in the tool and can be used easily. To use the ThingsPrO ontology, a user can click and open the button labeled as "Open Ontology File" in the tool (see area 3 in Figure 3). Once the button is activated, the same panel will provide all the available concepts defined in the ThingsPrO ontology.

Likewise, the user will be able to select the concept suited to their activity and associate it to them via text annotations. To assist the user in selecting the ontology concepts related to an activity, we provide a recommendation mechanism. Once the user clicks the "ontology" button on the top (see the top of area 1 in Figure 3), the system generates a form asking the task to which the resource (ontology concept) needs to be annotated. The system then recommends the ontology concepts closest to task based on the semantics of its label text. As discussed in various research work, such semantic annotation facilitates process modeling without compromising on consumption of time and cognitive load.

Figure 3: IoT resource association and ontology annotation to process illustrated in Figure 1
4.2.3 Ontology-based Knowledge Base

Figure 4 represents a prototype implementation to populate an ontology-based knowledge base using the concepts defined in the ThingsPro ontology. This knowledge base (KB) contains the IoT related information such as constrains along with the process models enriched with concepts from our semantic model (ThingsPrO), which contains the concepts from both the BPM domain (reuses concepts from the BPMO ontology) along with the IoT domain (reuses concepts from the FIESTA-IoT ontology). Thus, as the process models in this KB are annotated with concepts from ThingsPrO, the KB can easily handle processes modeled in different modeling languages (BPMN, EPC etc.). This is because they become semantically equivalent at the meta-model level due to the use of generic concepts from BPMO ontology. Furthermore, these models also contain annotation for IoT concepts, making them semantically equivalent for using the IoT resources (and their data) during the process execution phase. However, in this thesis, we do not go into the details of handling or processing IoT data based using our ontology.

Concretely, for creating the ThingsPrO ontology we used Protégé ontology editor. Next, the ThingsPrO ontology is used to build the knowledge base in the form of RDF triples. To use this knowledge base and the triples in a scalable manner, we use an open-source database engine for tripelstores from OpenLink Virtuoso. The triplestore server can be easily accessed using the Virtuoso Jena Provider API. By using the SPARQL endpoint supplied by OpenLink Virtuoso, end users (or system) can easily retrieve and manipulate information using SPARQL queries. This knowledge base containing information about the IoT resources and the process models enriched with the IoT concepts along with the relations between them. It will foster interoperability between processes and underlying heterogeneous resources as the users can define various links and relationships between the resources. Additionally, this knowledge base will be queried during the time of conflicts to resolve conflicts based on strategies defined in SWRL rules.

Figure 4: Screenshot depicting information retrieval from KB

Tool Usage

The Signavio process editor (open-source license: GNU GPL v3) allows designing of business process models in an intuitive (drag and drop) manner. It support the BPMN 2.0 standard.
A user can create the process model having various activities, by selecting the BPMN elements and corresponding IoT resources from the "Shape Repository" (left-hand side). As seen in Figure 5, we drag and drop the "Sensor" element and associate it to the activity "a1" in the process.

Figure 5: Associating the IoT resources to the activity

To use the ThingsPrO ontology, a user can click and open the button labeled as "Open Ontology File" in the tool. Once the button is activated, the same panel will provide all the available concepts defined in the ThingsPrO ontology. Likewise, the user will be able to select the concept suited to their activity and associate it to them via text annotations.

However, to assist the user in selecting the ontology concepts related to the activity, we provide a recommendation mechanism as show in Figure 6.
1. Once the user clicks the "Ontology" button on the top, the system generates a form asking the task to which the resource (ontology concept) needs to be annotated.
2. The system then recommends the ontology concepts closest to that task based on its label.

Figure 6: Selecting activity to be annotated with ontology concepts

Overall, our tool helps to enrich the business process models (BPMN 2.0) with IoT resources and annotate them with the ThingsPrO ontology. Moreover, with the use of ThingsPrO ontology the dependencies between activities and IoT resources are explicitly modeled. This helps in avoiding ambiguity and managing conflicts.

Contributors

  • Kunal Suri, CEA LIST and Télécom SudParis
  • Walid Gaaloul, Télécom SudParis
  • Arnaud Cuccuru, CEA LIST
  • Sébastien Gérard, CEA LIST

Labs Involved

Contact Details

    Kunal Suri
    Computer Science Department
    Télécom SudParis (Institut Mines-Télécom)
    9 rue Charles Fourier, 91011 EVRY Cedex, France
    Email: kunal.suri (-at-) telecom-sudparis.eu