IoT-Driven Workflows for Risk Management and Control of Beehives

Abstract

The internet of things (IoT) and Industry 4.0 technologies are becoming widely used in the field of apiculture to enhance honey production and reduce colony losses using connected scales combined with additional data, such as relative humidity and internal temperature. This paper exploits beehive weight measurements and builds appropriate business rules using two instruments. The first is an IoT fixed scale installed on one hive, taking rich continuous measurements, and used as a reference. The second is a portable nomad scale communicating with a smartphone and used for the remaining hives. A key contribution will be the run and triggering of a business process model based on apicultural business rules learned from experience and system observed events. Later, the evolution of the weight of each individual hive, obtained by either measurement or inference, will be associated with a graphical workflow diagram expressed with the business process model and notation (BPMN) language, and will trigger events that inform beekeepers to initiate relevant action. Finally, the BPMN processes will be transformed into executable models for model driven decision support. This contribution improves amateur and professional user-experience for honeybee keeping and opens the door for interoperability between the suggested model and other available simulations (weather, humidity, bee colony behavior, etc.).

1. Introduction

Beekeeping is a branch of agriculture that involves the breeding of bees (Apis Mellifera) to exploit the products of the hive, mainly honey. Apis Mellifera is a semi-domestic species that has been widely used since antiquity, not only to produce honey, wax, and pollen, but also for its prominent role in pollination, especially of vegetable and fruit crops [1,2].

According to the European Professional Beekeepers Association [3], many statistics that pertain to beekeeping consider professional beekeepers as only full-timers. However, in common practice, we can mainly distinguish three categories of beekeepers according to the importance of their operation. The first, amateur beekeepers, who have a family-friendly practice, own up to 50 beehives. The second category is made up of professional beekeepers who can own more than 150 beehives. Finally, beekeepers who own between 50 and 150 hives are considered as semi-professionals. Generally speaking, professional and semi-professional apiculturists reallocate their hives with respect to the blooms whereas amateurs do not necessarily.

In his 2009 book, Nicola Bradbear [4] stated that pollination is an indirect use value that stems from apiculture. In fact, insects, either directly or indirectly, are responsible of around one third of the pollination process of all plants, or plants products, consumed by humans. Among all pollinating insects, bees play the major role. In Western Europe, for instance, the worth of bee pollination is assessed to be 30–50 times the value of direct honeybees’ production [5]. In Africa, bee pollination is sometimes estimated at 100 times the value of direct production. Thus, it is estimated that the economic value provided by bees during pollination is out of all proportion to that of bee products.

As a response to colony collapse disorder (CCD), where major decrease in honeybee colonies is reported all over the word [6,7,8], advancement in technology is playing a major role in preserving honeybee’s species, pollination, and biodiversity sustainability [9,10]. In that context, Industry 4.0 and IoT technologies are playing a major role [11], where the use of sensors, networking, and artificial intelligence (AI) in addition to models, simulations, and process discovery are transforming current industrial processes [12,13,14]. In fact, the implementation of technology in Beekeeping dates to 1907 when Gates [15] measured temperature for many consecutives days.

With technology and IoT evolving, more accurate, small size, and low-price sensors became available in the market, ensuring a non-disturbing data collection environment [16,17]. Thus, more measurements related to the honeybee colony can now be collected, such as image [18], relative humidity [19], sounds, internal temperature, weight, forager traffic, and gases [20,21].

In 1990, Buchman and Thoenes [22] introduced continuous weight monitoring using a precision scale connected to a computer and collected data every 15 min for one month. Subsequently, many other studies showed a correlation between weight fluctuation and activities occurring inside the hives [23]. For instance, in 2008, according to Meikle et al. [24], the hourly weight, measured using electronic scales linked to data loggers, was calculated to derive the weekly running average weights. Later, the weights associated with the changes in food stores were correlated with humidity ratio changes and foraging activities, which were classified as daily fluctuations. In 2013, Human et al. [25] stated that the weight of full colonies can be measured to examine the nectar flow occurrence during the foraging season or daily gain in nectar stores, the decline of food stores during nonforaging periods [26], and the occurrence of swarming events [24]. In addition, the authors provided examples of applications of honey hives weight measurements networks in different countries, such as Germany, USA, Denmark, and Switzerland. In 2015, Sandra Kordić Evans [27] proposed an embedded hive system that measures weight, temperature, and movement using an accelerometer. Meikle et al. [28], in 2016, added to their previously mentioned work with a temperature analysis by installing sensors in different positions in the beehive and found the corresponding position by correlating each position’s temperature variations with its exterior conditions. Anand [29], in 2018, proposed a system that uses many combinations of the weight with sounds, relative humidity, and brood temperature to detect honeybee swarms based on several techniques and methods.

The present study does not yet contain complete results. The described items are examples of apiary data coming from an existing shared database [30] (Section 2.2.1) with other measurements provided by Connecthive [31]. Starting from such items, we propose a methodology based on pattern recognition within data recorded through both a static hive scale on one hand and a portable nomadic hive scale on the other hand. The proposed method focuses on weight measurements, and will be considered by introducing two types of measurement: an on-board IoT with richly measurements installed on one witness hive and a nomadic weight measurement scale system used for the adjacent hives. Later, the data collected will be assessed and combined on the server (Section 2.2.2 and Section 2.2.3). Finally, this method will contribute to reduce the overall cost by proposing the nomad scale solution instead of installing a scale for each hive.

Moreover, the back-end server will be responsible for the processing and labeling of the collected raw data by discovering recurring patterns associated with events occurring inside the hive. Then, detected patterns will automatically trigger a series of predefined actions based on workflow rules and static models built with the help of experts in the domain (the community of beekeepers using the system) (Section 2.3.2). Finally, all the above will be orchestrated within a user-friendly interface on a smartphone or a tablet where the beekeeper can easily monitor his colony, perform his daily tasks, respond to alerts for possible malfunctions, and forecast his future needs for supplies. As beekeeping tasks cannot be automated, and personal intervention is mandatory, the proposed system will help the beekeeper to plan several relevant tasks precisely: raising and breeding new colonies, feeding the colonies, adding supers, planning sanitary operations, controlling varroa mites, planning operations such as hibernation, etc.

As the system will not be dedicated only for professionals, but also for amateurs, it will encourage a larger number of people to be engaged in the beekeeping field, which can have a positive impact on the environment, biodiversity, and society. To achieve that purpose, a gamification approach will be followed by building a user-friendly interface with voice recognition and image capture features that facilitate the management of a large numbers of hives.

Gamification as a term was introduced for the first time in 2002 by Nick Pelling but it did not gain people’s attention until year 2010 [32]. Pelling originally defined gamification as “transferring game environment user interface to the electronic world by making it an entertaining and fast user experience”. Nowadays, gamification can refer to “implement main game design features into a real-world application” [33] to motivate and attract users with a professional application in an engaging game-like context [34].

In this context, the system will propose step by step actions and countermeasures to be taken with respect to a set of notifications and alerts reflecting the beehive status in real time. Finally, precision beekeeping [35] is a method of beehive management that relies on the monitoring of honeybee colonies for the reason to minimize supplies expenditure and maximize the honey yield production. Just like the principles already existing in precision agriculture, it is divided into three phases: data collection, data analysis, and the application of decision support for the beekeeper. While collecting the data, measurements are gathered directly from the hives: weight, temperature, and internal humidity, etc. The data analysis phase makes inferences from predefined models often based on artificial intelligence or on expert systems. During the decision support phase, recommendations are submitted to improve the performance of the apiary. Thus, beekeeping, like other fields of agriculture, must initiate a digital revolution. As the conditions of beehive exploitation becoming more and more complex, particularly due to environmental factors, the management of the farms must be rationalized to remain profitable, to produce better quality honey, and to minimize the losses of livestock [36]. Indeed, it is essential to maintain the population of honeybees without which the pollination of crops could no longer be ensured, causing considerable economic and societal damage [37]. The goal here is to use technologies based on a workflow engine, including business rules, and deep learning to help the beekeeper to better manage his bee colonies by monitoring and automating some of his decisions. In this context, the decision support system makes it possible to predict the evolution of each colony and suggests certain breeding operations to be carried out to improve the productivity and survival of the colonies. The contribution of digital techniques should pave the way for precision beekeeping, to minimize invasive treatments and synthetic inputs [38].

2. Materials and Methods

2.1. Experimental Scenario and Methodology

A decision support system will be installed in two professional beekeeping farms (more than 200 hives), in 4 semi-professional farms (more than 50 beehives) and 4 amateur farms (less than 20 beehives).

Then, measurements carried out continuously are collected on the control hives by means of the static scales as well as the discontinuous measurements carried out by means of the mobile scales.

In addition, data will be collected from beehive visit reports entered by beekeepers using the apiary monitoring application on their smartphones. These reports are equivalent to the ground truth and are used to label the data.

Subsequently, a data mining phase will be intended to find emergences of the processes initiated by beekeepers. Therefore, the identified processes are formalized with BPMN. They are differentiated by the type of beekeeping (professional, semi-professional and amateur) and they are placed in a catalog. Processes are validated (method with expert observation, or through a simulator that will be developed using a multi-agent system) and this process catalog will be available to all beekeepers. The system uses it to issue detailed operational advice.

Figure 1 illustrates the proposed methodology which consists of the three main steps: data collection, build time, and run time. Each step, in addition to the relations between different pillars, will be fully discussed in the upcoming sections.

2.2. Data Collection

As mentioned in Section 1, the proposed system is still under development, and although, only the weight measurement collection will be considered in this paper, it is planned to add other measurements as shown in Figure 1a. Data will be collected from different sources such as: hive’s weight, weather, external temperature, vegetation and flowers maps, internal temperature, relative humidity, etc. In addition to the mentioned sources, collaborative data will be gathered from different users to enhance system’s performance, especially in business rule discovery and simulation.

Whereas many data collection tools will be added to system in the future, the newly proposed weight measurement method will be fully discussed in the following paragraph. This method involves two types of weight measurements, namely continuous and discontinuous, as shown in Figure 2.

2.2.1. Datasets

Our data were obtained from HOBOS public dataset [30] with additional measurements provided by Connecthive [31]. HOBOS data originate from Wurzburg and Schwartau in Germany for the period between 1 January 2017, and 19 May 2019, while Connecthive data were collected from Villefranche de Rouergue in France between February and November 2019, as shown in

Table 1. Weight data measurement conditions.

Location	Number of Hives	Observation Period	Sampling Frequency
Wurzburg	1	2017 to 2019, 1 January 2017 to 19 May 2019	1 sample/min
Schwartau	1	2017 to 2019, 1 January 2017 to 19 May 2019	2 samples/day (at 1 a.m. and 1 p.m.)
Villefranche de Rouergue	20	February 2019 to November 2019	2 samples/h, up to 1 sample/min

. This table shows, from left to right, the location, the number of hives, the observation period, and the sampling frequency. The weight of the beehive through time is measured in Kg for the hives of Wurzburg and Schwartau, while that of the hives of Villefranche de Rouergue is measured in grams. Note that, between May 2018 and October 2018, there is missing data from the Wurzburg hive because the system was down. It is important to mention that the temperature of the beehive through time, the humidity of the beehive through time, and the number of departures from and arrivals to the beehive for a certain date are available with HOBOS dataset, but they have not been used in the current study.

2.2.2. Global Collection of Information on Beehives

In the market there exist several companies that provide tools and methods for global data collection from the beehives, as shown in

Table 2. Similar solutions comparison.

	IoT	Humidity	Weight	Sound	Temp.	Theft Alarm	Realtime Data	Alerts	Mobile App.	Nomad	RFID	Workflow	Smart App
Arnia [39]	✔	✔	✔		✔	✔	✔	✔	✔				✔
ApisProtect [40]	✔	✔		✔	✔		✔	✔	✔				✔
BeeHive Scales [43]	✔	✔	✔		✔		✔	✔
SolutionBee [43]	✔		✔		✔		✔	✔					✔
Broodminder [44]	✔	✔	✔		✔				✔
Osbeehives [45]	✔	✔		✔	✔	✔	✔	✔	✔
ConnectHive [31]	✔	✔	✔		✔		✔	✔	✔	✔	✔	✔	✔

. We can mention several examples such as: BTS, Arnia [39], ApisProtect [40], Beeehive Scales [41], BuzzTech [42], SolutionBee [43], etc. Moreover, open data sources also could be available online as shown in Table 1. Although hives measurements performed by Arnia [39], for instance, might look the same, the reason behind the choice of Connecthive [31] over similar service providers is, first, that open-source data exists on the internet as fixed raw data which cannot be customized for the needs of our experiments nor extended, and second, the association of a nomadic scale and a fixed scale shown in Section 2.2.3, in addition to RFID tag and the automatic weight recording in the database for each single hive are unique and specific to Connecthive, as there is no similar approach by other compagnies. Moreover, the workflow approach, a specific subject of this paper, will be elaborated more in Section 2.3.2 and Section 3.3.2.

Connecthive is a company that develops beekeeping data acquisition systems based on the one hand, on measurements taken from on-board sensors in a few witness hives (so-called richly measured), and on the other hand, from a nomadic acquisition system associated with a voice input interface on tablet or smartphone. The nomadic system is moved to all the hives (said to be weakly measured) during the visits made by the beekeeper. Weight measurements are smoothed out to disregard variations caused by wind. Regarding the support, the hives are placed on a horizontal support even if the ground is not. The data collected are fed back in real time or in deferred mode (thanks to an IoT network) on a server which aggregates it. A rich measurement includes the following quantities in particular: instantaneous weight of the hive, internal temperature, and hygrometry of the swarm, rustling of the swarm, outdoor temperature and hygrometry, wind speed, duration of sunshine, inbound and outbound bee traffic, level pollen collection. A weak measurement includes the following quantities: hive weight, swarm size measured by thermography, instantaneous traffic level capture (short videos), automated varroa count (still image processing). In addition, observed but non-metrological observation data supplement this weak measurement, in particular: surface area and type of brood, number of frames occupied, possible pathological signs.

Although in this study only continuous and discontinuous weight measurements will be considered, the integration of other input data will be part of the future work.

As for the data transmission, GSM, SIGFOX, and 4G are used for communication between the four main layers, i.e., device layer, operation layer, backend layer, and management layer, as described in Figure 3. In the case of network shortage, the replication mechanism synchronizes the same data among the three layers as soon as the respective networks (GSM, SIGFOX, and 4G) are reached. The data structures increase in complexity as the layer is higher. Finally, it is essential to mention that, in Lebanon, there is no SIGFOX. Thus, GSM and 4G are only considered.

2.2.3. Weight Measurements

As illustrated in Figure 2 and Figure 3, continuous measurements are taken by a stationary scale connected to the cloud, whereas the discontinuous measurements are carried out with a mobile (portable) scale, which is also connected to a network. Beehives weighed with the mobile scale are automatically identified with an RFID tag and the weight data are recorded in the user’s smartphone before being consolidated in the cloud.

The discretization of measurable data into events associated with a finite time is the foundation of today’s computation theory [46]. Data from observed events are stored after appending it with a timestamp. This discretization is due to the clock-based nature of computers. However, the physical time is continuous, and physical quantities not acquired by the sensors (e.g., physical quantities at time instants different from sampling times) can still be estimated by interpolation or extrapolation, thus making the collected data virtually continuous. Signal processing techniques usually consider the continuous nature of such measurements and lean towards representing signals as mathematical functions. Meanwhile, on the other hand, discrete processing of large amounts of data might require enormous storage resources, e.g., in case of a large number of sensors, and/or data observation spanning a long period of time.

Discrete measurements can be considered continuous in case the sampling interval is as small as the sensor’s time resolution. For instance, if a sensor is capable of providing a maximum of one sample per second, then acquiring a measurement every second is continuous relative to that sensor’s performance. In this project, we exploit this type of continuous measurement, namely instantaneous weight measurements of a reference hive, coupled with discrete measurement samples, approximately a week apart, acquired from all other (non-reference) hives in the apiary.

As mentioned earlier, the proposed system relies on external weight measurements. Because the weight measurement of each beehive is too expensive, the weight of one beehive per apiary is continuously measured and the weight of all the beehives is measured one time each week. Therefore, the challenge resides in inferring continuous weight variations of each beehive from the variations of the continuous measures. To do so, two types of scale are used: a continuous (stationary) and a discontinuous (nomad) scale. More precisely, the continuous scale is used to measure different parameters of the hive over a specified region, using a mobile sensor. A fixed device can be associated with this mobile sensor under the control hive which is later equipped with fixed sensors for weight, temperature, and videos analysis. All measurements are stored in the database to use them to control a hive simulator. The constant recording of the weight, temperature, and humidity, applied over the control hive, relates to the spot records made on each hive separately, using the discontinuous scale. These accumulated data can then faithfully reflect the situation of the colony by giving it a unique profile using artificial intelligence (AI).

Note that the continuous scale is connected to the IoT by Sigfox or by mobile data networks (2G–3G). It can also be disconnected. In this case, data are uploaded to the apiarist’s smartphone when nearby, using Bluetooth. The discontinuous scale is always connected to the apiarist’s smartphone. An illustration of the continuous and discontinuous weight measurements is presented (Figure 2).

2.3. Build Time

We carried out a proof of concept based on the data coming from two apiaries: Wurzburg (Center of Germany) and Villefranche de Rouergue (South of France). The results of this proof of concept are not sufficient as apidological results but allow us to design the methodology of our project. After a simultaneous data collection, weight variation patterns will be identified for data labeling and events association. These events will trigger on the predefined BPMN workflow model a sequence of automated business rules in response to the hive’s events. Weight patterns discovery and BPMN workflow will be discussed in Section 2.2.1 and Section 2.2.2.

2.3.1. Weight Patterns Detection and Analysis

The study is divided into four main sections: (1) provision of datasets containing the weight and ambient temperature; (2) loading, cleaning, and smoothing the data; (3) analysis of weight and temperature fluctuations; and (4) results validation.

• Data preprocessing

In the first phase, datasheets containing the recorded weight with the corresponding timestamp are cleaned. All invalid date formats and unusual weight values are eliminated. For an enhanced analysis, the smoothing is used to eliminate minor variations in the data and to make the difference between the samples uniform. In addition, the smoothing method calculates the average of the weight between two samples having the difference in time equal to the window given.

• Data analysis

The analysis is divided in two parts: the monthly and daily analysis. In both parts a linear regression is fit to the model used to find a correlation between the time and the weight. The coefficient of determination R2 and the slope are both used to interpret the variations.

In the monthly study, events are analyzed depending on weight variations and the current season. The data are resampled to 12 h and sets of monotonous samples were analyzed consequently. Each set follows a linear regression, and the slope is then used to give the appropriate interpretation for the remarkable changes in a single frame.

In the daily analysis, the parameters considered in the study are the weight, the time of the day, and the outside temperature that is categorized into three sets. The data are resampled to 1 h, then split into three parts: the inactive period, from midnight until dawn and dusk until midnight, and the active period from dawn until dusk. In each part, monotonous segments are fit to a linear regression model, where the slope is utilized to determine the corresponding events. As a first step, three temperature ranges are identified too cold (below 12 °C), normal (between 12 °C and 35 °C), and too hot (over 35 °C) [47]. Then, in each range and depending on the time of the day, an appropriate interpretation is generated. Finally, all detected events and patterns are displayed on daily and monthly plots that show each continuous weight variation analysis in a specific color along with its corresponding label. The results are validated from independent datasets from France and Germany.

The data is smoothed using a running average window. Noise resulting from beekeeper intervention or system failure is excluded from the dataset. Below, Figure 4 illustrates examples of detected patterns based on data collected by Connecthive and correlated with beekeeper observation from the hive.

2.3.2. Business Process Model and Notation (BPMN) & Workflows

Regarding apiculture best practices, two business process models are built. The first model is a result of face-to-face interviews with three different amateurs beekeepers in Lebanon. All common practices were validated, and a comprehensive synthesis is built accordingly before building the model itself. The resulting (BPMN) model for amateur beekeepers consists of around 60 gates. As for the second model, it is built with professionals in the domain and is an outcome of many meetings with a leading company in Lebanon, l’Atelier du Miel [48], where to better organize the received information, an excel file was created to describe the beekeeping process taking into consideration several parameters, such as hive’s status, region, altitude, etc. In addition, Connecthive [31] also provided us with pseudocode that illustrates some of the beekeeping processes shown in Figure 5. The resulting (BPMN) model for professional beekeepers consists of more than 100 gates.

Table 3. Extract from the beekeeping best practices Excel file.

Atelier du Miel|South, Lebanon
Altitude	Starting Day (MM/dd)	Season	Flower	Hive’s Status
(0–450 m)	02/15	Spring	Citrus & Avocado trees	Colony Developpment
Regular Tasks		Actions taken to be taken
Checkup every three days		Check for colony expansion
		Check for supplies
		Check anomalies
Check queen strength		Check if eggs are placed from middle to out
		Check queen activities (Circular, fast, organized)
…		…
Anomalies		Actions taken to Countermeasure Anomalies occuring in the hive
Old queen		Terminate (Could be terminated and replaced)
If Varroa Detected		Treat and reallocate for one week to avoid infection
		Keep checking till varroa is cleared
		Return the hive if varroa free
If Mold detected		Sperate/Eliminate infected frames from the rest
		Eliminate any cause of humidity
…		…
Connecthive |Villefranche, France
Altitude	Starting Day (MM/dd)	Season	Flower	Hive’s Status
(0–450 m)	09/15	Fall	Few flowers	Wintering Mode
…		…
Anomalies		Actions taken to Countermeasure Anomalies occuring in the hive
Shortage in honey Supply		Feed with Liquid Proteins and check for absorption.
		In case there is no absorption, feed with Candyboard.
…		…

illustrates an excerpt from the mentioned Excel file as the result of many interviews with l’Atelier du Miel [48] correlated with provided data from Connecthive [31], France during spring season and fall respectively. The table describes as mentioned previously: the region, altitude, the starting day, the season, flower types and hive’s status. Moreover, in the table, we can distinguish two main categories of tasks with their respective actions and countermeasures: regular daily tasks and anomalies detection. Please note that this is only an excerpt of the original file and the provided information in the table is not exhaustive but is given just as an example. Finally, the same type of anomalous events provided by Connecthive and shown in the bottom of the table, will be fully discussed in Section 3.3.

In this paper and to avoid complexity, only a simple model will be considered taking only into consideration the hive’s weight and the season and was built from the pseudo code shown in Figure 5. The BPMN model will be shown later in the results section (Section 3.3.2). To perform the modeling, business process model and notation (BPMN—OMG, 2013) [49] is deployed. BPMN 2.0 makes available a set of modeling objects allowing any organization (industrial, health, military...) to represent their business process.

The aims of BPMN are to be “readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the businesspeople who will manage and monitor those processes”. At the descriptive layers, the proposed modeling objects allow to build a process model to understand what an organization do and how it works [50].

At the analytic level, BPMN allows to deploy key performance indicators (KPI) to make analysis of processes to improve performance. To this purpose, first, BPMN is easily extendable to integrate specific attributes, concepts, or else relation to a process model and to use it as analysis entities [51]. Second, tools currently available to use BPMN often integrate modules for process analysis and continuous improvement.

Lastly, at the executable level elements, such as data used, actors involved within the process are added to run the process. In the same vein as for the analytic level, tools available to integrate the workflow engine are able to interpret these elements and to execute processes.

Regarding the last point, the concept of workflow is considered. The notion of workflow emerged in the late 1960s [52] in the context of the evolution of information systems [53]. Several definitions have been proposed in the literature for the concept of workflow, including that of the workflow management coalition (WFMC), an organization that defines standards for the development of workflow tools [54,55]. Thus, a workflow consists of automating the flow of information in a process by providing each actor with the information necessary to carry out the activities that make up the process by following procedural rules. This is the reason why the process is modeled first (e.g., using formal models BPMN/DMN presented hereafter) to identify the parts that can be executed by a workflow engine [56,57] in order to drive the taking charge of a protocol.

3. Results

3.1. Weight Patterns Detection and Analysis

Results of the monthly analysis showed that negative slopes were linked to the extraction of honey and the number of bees declining in summer/spring whereas it symbolized the death of bees in winter/fall. Positive slopes showed honey production, adult bees forming and occasionally beekeeper intervention in the summer/spring. Figure 6 shows normal variation over one month in spring, moisture changes (in red), adult bees forming and honey production (in blue), and some loss in the number of bees and honey store (in green).

Regarding the daily analysis, for temperatures lower than 12 °C, results showed that weight fluctuations were often linked to ventilation, food consumption or beekeeper intervention during active periods, or dryness and moisture during inactive periods since it is considered too cold for the bees to leave the hive. Temperatures between 12 and 35 °C were found to be optimal for foraging activities. In the active period, weight fluctuations were mainly due to bees leaving and entering the hive, whereas dryness and moisture changes affected the weight in the inactive period. As for temperatures higher than 35 °C, the weight fluctuations would mostly be limited to ventilation and beekeeper intervention in active periods, and water vaporization and moisture change during inactive periods. Figure 7 shows a day with a normal temperature where dryness and food consumption (in magenta) occurred in the inactive period, while during the day, bees’ foraging activity (in blue) was observed.

3.2. Artificial Intelligence (AI) and Neural Network

In our datasets, a timestamp is associated with each weight sample. Thus, weight variations of monitored hives can be seen as time series that can be learned by AI models. Such models can be used to complement scarce weight samples obtained from the nomad scale for different hives (c.f. Section 2.2.1), thus inferring continuous weight variations that can be analyzed to identify patterns of anomalies or action-triggering events. Furthermore, AI models can be used to predict future weight variations following an initial observation interval, such that the beekeeper can be alerted about any potential anomaly or trigger ahead of time, allowing for an early intervention whenever necessary. This can also be of utmost importance whenever the monitoring device goes down, due to a power failure or defective sensor for example, thus providing an uninterrupted flow of hive weight data which can reduce the risk of unreliable pattern detection and faulty triggers.

In its early stage of development, a recurrent neural network, namely long short-term memory (LSTM) [58], was designed to predict future weight variations for a beehive. Our model consists of three LSTM layers of 32 units each, separated by a dropout layer with dropout probability of 25%. A sliding window feeds the input layer with a number of consecutive input weight samples to predict the next sample value at the output layer which consists of a single node. The LSTM architecture is shown in Figure 8.

The model was trained and tested with weight measurements from Wurzburg and Schwartau in Germany and Villefranche de Rouergue in France. For each hive, the first 50% of weight samples are used to train the model. Training is performed for 100 epochs with Adam optimizer [59]. Figure 9 highlights a significant weight loss over two months in the late summer-fall be-ginning causing the beekeeper intervention to provide nourishment to the bees, based on Schwartau hive data. After roughly one month of continuous weight loss, the next five-day measurements are fed to the model. Following this initial observation time, the model is used to predict weight variations for the next two weeks. A sliding window considers 10 most recent samples (i.e., five-day peri-od, two samples/day) to predict the expected hive weight within the next 12 h. This window is moved repetitively until a critical weight requiring the beekeeper’s intervention is detected. The figure shows that the model was able to predict on 17-08-02 that the hive weight might reach 59 Kg on 17-08-26, with an error of 1 Kg compared to the real measured weight, representing a total loss of 9 Kg within a period of 2 months. The model also predicted a beekeeper’s intervention to occur on 17-08-27, one day earlier than the real beekeeper’s intervention, as it was trained on data with such beekeeping practice after a significant weight loss within a hive. Without any intervention, further weight loss would be expected for the hive. Therefore, the model allows the system to trigger an early alarm, alerting the beekeeper of a required intervention ahead of time.

3.3. Process Models and Gamification Approach

3.3.1. Gamification

“Getting things done” (GTD) [60] planning will provide the user with an easy and smooth experience whereby he will receive step-by-step notification on his mobile or tablet concerning where he will be interacting respectively with each move in a simple, gamified, and clear way (Figure 9). In addition to its superfast speed, the application will be designed to generate statistics, work in offline mode, and synchronize across multiple devices.

The system is designed to gain users engagement in the beekeeping domain, regardless of their previous experience in the field, in a consistent, easy, and joyful experience based on a rich data base system (Figure 1a), with a game-like user interface, and a collaborative ecosystem that will be developed later as part of future work.

The novelty of our gamified approach resides in the workflow engine that drives users’ actions. The workflow is described in BPMN language and detailed in Section 3.3.2.

3.3.2. BPMN Model

As previously stated in Section 3.3.1, the BPMN is driving the gamification concept by involving the user in the process and guiding the activities to be done. For each event, a series of respective actions will be triggered and pushed on the user’s mobile in the form of a notification, in a step-by-step gamified way, similar to the gaming environment, wherein the user can achieve a level only by completing all required steps.

As previously discussed in (Section 2.3.2) for simplicity, a simple BPMN model (Figure 10) was built after the pseudo code (Figure 5) provided by Connecthive [31].

Discovered patterns from the processed data, previously discussed in Section 3.1, will trigger events on the BPMN model and the user will be notified on his mobile phone and respective action will proposed either to perform a daily task or to countermeasure any malfunction occurring in the beehive, as shown in Figure 10 and Figure 11. Moreover, this model will not only be used to trigger events according to the present time data, but it can also be used later in simulation to forecast future anomalies or simply to predict the hive’s needs for wax and other supplies.

The red arrow in Figure 10 indicates a critical decrease in the hive weight previously detected and discussed in Section 3.2 as well as shown in Figure 9 and Figure 11. This critical decrease will trigger on the BPMN model an event to feed with liquid nourishment. This event will be communicated to the apiarist in the form of a message displayed on his mobile as shown in Figure 11.

In the above suggested model, an apiarist receives an informative message (1) about the provisions status at the hive, and if sufficient, the system will inform the user to enter the wintering mode (4). If insufficient provisions are detected, the system will enter in weight measurement mode. In this case, the assessment will be based on the date. In case the date is less or equal to 28 August, the apiarist will be alerted in a message (3) to nourish the hive with 6 kg of liquid feeding. After that, the beekeeper will check for the absorption of the nourishment, and if the weight is not reached, the process will be forwarded to candyboard feeding, where the colony is provided at one time with a sufficient quantity to reach 35 kg. The weight will be checked, and the hive will enter the winter mode without waiting for absorption. In contrast, if the date is exceeding 28 August, the apiarist will be alerted in message (5) to feed with solid food (candyboard), check the weight without waiting for absorption, and finally enter wintering mode. Messages 1–5 are illustrated in Figure 11.

To obtain a quick and clear insight about what the output and the messages could look like, Bonita software was used, as illustrated in Figure 12. It has been already deployed on smartphones for test and validation, as presented in Figure 11, on pilot hive farms. Access and response time are already satisfactory in case the cellular network is sufficient.

4. Discussion

The work proposed in this paper presents some methodological achievements in the field of beehive keeping control thanks to electronic data and remains in progress. It included the data chain from information obtained using IoT devices, workflows in the form as BPMN models, and triggering events for those models based on patterns detected in incoming data. The model-to-model approach is under development. The model transformation is not automatically done yet, but testing over pilot hives in France and Lebanon provided encouraging feedback. Moreover, the final implementation of the main key performance indicators is still under discussion.

In the context of driving and automating model transformation, authors identified several approaches, such as model driven development (MDD) within the framework for modeling simulation (MDD4MS) [34], the model driven service architecture (MDSEA [61]), the model driven interoperability for system engineering (MDISE [28]), and in this domain, “Beeomatics” [31], that can guide conceptual domain models to formal and executable models. The targeted formal models can be either used for simulation or execution of the models. As a result, the framework will integrate a transformation of BPMN models into execution and simulation models based on previous research in this domain to simulate and orchestrate/execute process models.

In any case, the interoperability will still be considered as crucial either for data or models since data can be heterogeneous, and process can integrate different data sources. The interoperability of processes will aim to make various processes work better together. These processes will clearly define in which order services (functions) are to be executed according to the business rules [62].

As a first perspective, models are required to clearly capture the decision to be taken. For instance, the Object Management Group offers several languages that are compliant and complement BPMN onto specific features. Thus, let us mention Decisional Model Notation (DMN—OMG 2015) [63], allowing to model and represent decision and business rules within an organization. This notation is usable with BPMN and intended to be usable by businesspeople and technical people as well. In the frame of the management of a beekeeping exploitation, it will be interesting to build a set of business rules fully readable by business users and combine this kind of language with BPMN allowing to design, describe and automatize decision within a process. The DMN model will be used to pave the way and better formalize decisions in the target execution model. Moreover, the automatic model discovery and process mining will be considered as a path to capitalize on process models from historical data regarding domain practices.

Then, this work will integrate some tailored simulation code to run the dynamic animation of the BPMN model, in order to help users when facing risk in the hive. It will be proposed for a didactic purpose and decision support [64]. Considering simulation as another target model, the model-to-model transformation from BPMN as a conceptual modeling language to DEVS as a simulation model specification appears promising to run simulation and provide user decision support before choosing an action to perform. We propose to inscribe these works in open-source development frames.

The system provides recommendations for actions to be carried out to optimize the monitoring, management, and production of all apiaries. These recommendations are based on macroscopic events that originate from multiple sources of information constituting the data model, and from a behavioral model (BPMN) describing the activity of management of the apiaries. The events considered by the model can be the result of an aggregation (multicriteria) of the data collected from apiaries and from environment (weight, humidity, temperature, weather data, geographical data, video of apiaries, ...), which may be the result of business experience or learning process or both.

In addition, and as part of the future work, the apiarist will be able to choose a predefined workflow which best fits his needs or build a new one from scratch. More, beekeepers will have the choice to work in a collaborative environment where they can share their experience with local and international apiarists. The flowering and vegetation maps will be established in a collaborative way by the beekeepers of each region who will provide their own observations. The server will transform the collected data into a cartographic representation. In fact, the collaboration environment will be considered as a win-win situation since the user can benefit himself and transfer his expertise and useful information to local or even international beekeepers as well.

This cooperation will strengthen and improve practices while the system will be designed in such a way to preserve privacy for all participants. Moreover, due to multiple data sources (e.g., relative humidity, relative temperature, weather, image, sounds, etc.) and rich database system, the simulation feature will enrich the apiarist’s experience and help him to manage his stock by forecasting his needs for supplies and of course will give him an eye on the production and profit. The modeling and simulation will also enhance the system’s performance as far as countermeasures to be taken, based on similar previous scenarios in the past.

For now, inputs are mostly composed of hives’ weights. Other information, such as weather, ambient temperature, internal hive temperature and hygrometry, and flowering, coming from the web can be added to complement the source of inputs and provide greater insight and confidence regarding the patterns of events that trigger the process models. The functioning of used IoT and extracted data format are fully known at this stage to show the usability of the approach. In the end, the final proposed application will have to allow different IoTs to inject their own data into models. Generic and interoperability mechanisms will have to be provided to allow users to exploit their own IoT and data formats without interfacing effort.

Moreover, the gamification concept will be pushed to its extreme by allowing different apiarists to share their problems, post solutions, trade ideas, and interact one with another. In fact, a rich collaborative data base collection will enhance the system’s performance regarding simulation and will improve the decision making by proposing more accurate response to problems occurring inside the hives. Such a system will promote cooperation within national and international beekeepers’ communities which will contribute to growth in the field.

5. Conclusions

In summary, the interest of this work can be differentiated according to the target, hobbyist beekeepers or professional beekeepers.

For the hobbyist beekeeper, process models can underpin a gamification paradigm and provide guidance for beginners. The gamification paradigm is important for this user profile.

For the professional beekeeper (with around 1000 beehives), the benefit is the optimized management of his livestock and an improvement in livestock health. In our opinion, he can expect an increase in the profitability of his bee farm in the order of 20%. The contribution of technology comes down to reducing synthetic inputs and preserving the original purity of bee products.

The advantage of the system is to provide the beekeeper with a holistic view of his farm and a precise look at each of the hives that make it up. Thus, he saves precious time for his operational organization and is supported in his decision-making. As a breeder, he knows which strains he should favor to renew his livestock. Finally, he can finely adapt the level of health treatments to the strengthen the constitution of each colony. The very precise adjustment of this level is a condition for avoiding colony losses, for minimizing the amount of artificial feeding, and for favoring the treatments accepted under organic labels.