Process Optimization with Smart BLE Beacons ^†

Abstract

The optimization of workflows and processes based on available data and observations is very important for gaining efficiency, but is often limited by the amount of available information and the time required to collect it. In this paper we suggest a flexible solution, based on wearable radio beacons and software analysis of their inputs. A prototype of the system was built with NRF52832 smart tags and the Raspberry Pi 4 gateway and data analysis system. Experiments carried out on the first samples indicate that it is indeed possible to seamlessly collect and process information that is then used to optimize various actions, ranging from production to administrative tasks.

1. Introduction

Contemporary businesses exist in a competitive environment that requires the consideration of multiple scenarios and outcomes for every single decision that is made. To survive and thrive in such conditions, it is not enough to think carefully about every organizational and technological factor that may influence us, it is also necessary to stay alert of imminent changes in such an environment. In the case of the IT and software industry, the importance of these observations has found solid backing in the inherent flexibility laid down in The Agile Manifesto [1] principles. Yet, to fully implement not simply efficient workflows, but also ones that aim at continuous improvement, it is necessary to constantly monitor the environment and draw conclusions from the collected inputs. This is an expensive and tedious task due to the following reasons:

-

A lack of resources—the time and effort spent on monitoring and analyzing data is actually lost in terms of more productive tasks;

-

Design complexity—the implementation of custom solutions requires regular maintenance and education for staff;

-

A lack of motivation and trust—although this is solely a non-technical issue, it can easily counter any technologically advanced solutions as staff may refuse to cooperate, or even provide false inputs due to a fear of redundancy or higher workloads;

-

The safety of trade secrets and production information, which is important for retaining a competitive advantage.

Token tracking has long been a subject of substantial interest, as shown in [2,3]. In this paper we focus on an extended task of mobile radio tokens—involving the tracking, improvement and early detection of problems in the manufacturing process. Such a vision exceeds the mere asset tracking or control of individual operations, thus turning the individual tokens from a technical device into an important piece of the whole manufacturing management chain. This is achieved by providing flexibility in software implementation, opening the code and using a combination of sensors plus human interaction to be able to cope with challenging and non-trivial applications.

The idea is to achieve the real-time monitoring and identification of problems in manufacturing. As discussed in this paper, it is based on existing common radio protocols used for automation. We decided to experiment with Bluetooth v4.1 and v5.2 because of their wide acceptance and the myriad of devices supporting them—since this is a cost-lowering factor, it is essential to ease application in real-world scenarios. Due to the specific nature and functionality of the beacons, Bluetooth Low Energy (BLE) communication has been used to broadcast data to reception units. Positioning algorithms using individual tokens are well studied and discussed in detail in [4,5], and offer solutions for both ad hoc [6,7] and layout-/map-based identification [8]. While precise location is very important, for this particular study it is merely a prerequisite to achieve higher efficiency in production. In [9], it is described how beacons can be positioned in a way to minimize the number of needed devices and solve line-of-sight (LOS) issues in complex manufacturing environments, though this approach focuses on technological feasibility. In this study, we place the emphasis on the fact that individual beacons, data collection points and re-transmitters should be positioned in such a way that supports the optimization of the existing manufacturing and organizational processes, with the optimization of the number of devices and their maximum accuracy in terms of positioning still being very important, but ruled by the economic/production efficiency needs.

2. Design and Implementation Details

With the existing economic conditions worldwide, such as changes in supply lines and increasing uncertainty [10,11], it is extremely important for all businesses to remain flexible and implement every possible optimization to gain efficiency and be competitive.

To address these issues, we suggest a very simple and virtually non-intrusive technological solution that can monitor and analyze various parameters of a working environment and feed in the information for further analysis. The basic idea is based on multi-purpose beacons that, in addition to typical radio communication, can have very limited user interaction options like one or two buttons, which communicate their position and inputs (e.g., button events) to on-site data collection modules. These data reception points serve four main purposes:

-

The first is to make sure that individual token devices can remain in relative proximity to the reception point, thus reducing the radio transmission power and increasing the lifetime of the battery-supplied tokens.

-

The second is to provide redundancy, storage and data recovery in case of communication failures, as individual receivers can buffer data and keep local copies in case it is not possible to transfer the data to the central processing service.

-

The third is to provide service support functions, making it possible to remotely update the firmware of individual tokens and keep track of their usage.

-

The last but definitely not the least important purpose is to ensure the safety of the collected data, both at rest (as locally buffered information in case of communication troubles) and in transit—when sending the information for further analysis and processing.

In addition, every data reception unit can serve as a Bluetooth repeater and send further packages that require such a special service, thus increasing the effective range of communication for individual beacons. Since it is possible to keep these units constantly powered, that also helps in solving problems with power consumption and increases the useful lifetime of individual beacons. Offloading the data security tasks to the reception units also makes it possible to greatly simplify beacon firmware and further reduce their power consumption. To avoid sending plain data, symmetric encryption is used by the beacons when generating BLE packet payloads.

Figure 1 shows a high-level overview of the suggested system, which consists of:

-

Smart beacon devices with specially designed firmware and the capability of radio communication:

Smart beacons are built upon NRF52832, and the firmware has been implemented in C as a custom state machine (as shown on the left pane of Figure 2), thus newer variants of the Nordic Bluetooth chips are supported (including BLE 5 chips). We elected to experiment with this particular chip for two main reasons: (a) it is able to support older devices, thus bringing down the costs of various applications, and (b) the use of the BLE 4.x protocol would make it possible to easily test the boundaries of token applications in industrial environments, as the supported range is smaller compared to newer protocol versions.

Figure 1. System overview and high-level design.

Figure 1. System overview and high-level design.

Figure 2. Implementation details of the beacon (left) and the repeater (right).

Figure 2. Implementation details of the beacon (left) and the repeater (right).

-

Repeaters and gateways, which may vary in terms of numbers or features based on the monitored environment:

Repeaters and gateways are implemented as a standalone C++ application (as demonstrated in the right pane of Figure 2), running in service mode on a Raspberry Pi 4 (the older variant was used for testing, instead of the already existing Raspberry Pi 5, in order to assess the efficiency of the suggested solution when applied over old and proven hardware) device, with the use of either the built-in Bluetooth chip or a USB extension. These devices are designed to implement two main features of the system—first, to collect information from devices that are positioned at a specific location (thus making it possible to cover larger spaces without increasing the TX power of the individual tokens and retaining their battery power for a longer time) and second, to communicate the backend dashboard and analytical software.

-

Input analysis algorithms, depending on the optimization tasks and dashboard solutions, for visualizing the results:

For resource-constrained devices, as these beacons are, we opted for the BSON [9,10,11] data format and the MQTT [11] protocol, as shown in Figure 3, where three steps of an example process were tracked in length and frequency based on the input events from a beacon. To further reduce the payload, we tested the very simple compression approached of the BSON output with two methods—RLE [12] and RLE + BWT [13].

Due to the very short messages, there is no point in using BWT preprocessing before RLE is applied, as shown on Table 1. Therefore, we opted to use only basic run-length encoding, as the reduction in size is significant (36.4%) and the implementation does not require complex calculations. While preliminary tests confirmed that JSON/BSON messages are not really the best option for beacon communication, due to the extensive overhead, their use has one important advantage—they are human-readable and can be used as inputs for a vast range of data analysis software and cloud services. They are also very useful during debugging and the manual examination of the inputs. As seen in Table 1, the major consumer in the encoded message is the timestamp, due to the fact that we used a standard representation—seconds elapsed from 01.01.1970. That requires at least 4 bytes to hold a simple timestamp, which is not always needed for the studied application field. As an alternative, a 16-bit timestamp can be used, based on the following assumptions:

-

Time is measured as an offset of a frequently changing base (for example, the start of the day or the beginning of a work day/shift period).

Table 1. Simple protocol examples of tokens signaling specific events.

Event Description	JSON Message						BSON Data	Remarks
Button #1 key event press (1)	{“t”: 1746941707, “e”: 1}						(1) Raw BSON	Reduction in %
							0x13 0x00 0x00 0x00 0x10 0x74 0x00 0x0b 0x37 0x20 0x68 0x10 0x65 0x00 0x01 0x00 0x00 0x00 0x00	13.6%
							(2) RLE encoded	36.4%
							0x13 0x95 0x20 0x7 0x60 0x42 0x1b 0x20 0x50 0x41 0x28 0x6 0x20 0x9e	−5.3%
							(3) BWT+RLE
Button #2 key event press (3)	{“t”: 1746941707, “e”: 3}						(1) Raw BSON	Reduction in %
							0x13 0x00 0x00 0x00 0x10 0x74 0x00 0x0b 0x37 0x20 0x68 0x10 0x65 0x00 0x03 0x00 0x00 0x00 0x00	13.6%
							(2) RLE encoded	36.4%
							0x13 0x95 0x20 0x7 0x60 0x42 0x1b 0x20 0x50 0x41 0x28 0x6 0x60 0x9e	−5.3%
							(3) BWT+RLE
Custom protocol implementation
Button #1 key event press (1)	t	t	t	t	x	crc8	Compared to standard formats, binary representation is much more compact.	−68.4% (compared with plain JSON)
	68	20	37	0b	11	6c
Button #2 key event press (3)	t	t	t	t	x	crc5	It requires only 4 bytes for the timestamp and 1 or 2 bytes for the event information (suitable for simple events is a single byte, where 4 bits are used to identify the event type and another 4 for its source.	−57.1% (compared to BSON)
	68	20	37	0b	21	Fc

Table 1. Simple protocol examples of tokens signaling specific events.

Event Description	JSON Message						BSON Data	Remarks
Button #1 key event press (1)	{“t”: 1746941707, “e”: 1}						(1) Raw BSON	Reduction in %
							0x13 0x00 0x00 0x00 0x10 0x74 0x00 0x0b 0x37 0x20 0x68 0x10 0x65 0x00 0x01 0x00 0x00 0x00 0x00	13.6%
							(2) RLE encoded	36.4%
							0x13 0x95 0x20 0x7 0x60 0x42 0x1b 0x20 0x50 0x41 0x28 0x6 0x20 0x9e	−5.3%
							(3) BWT+RLE
Button #2 key event press (3)	{“t”: 1746941707, “e”: 3}						(1) Raw BSON	Reduction in %
							0x13 0x00 0x00 0x00 0x10 0x74 0x00 0x0b 0x37 0x20 0x68 0x10 0x65 0x00 0x03 0x00 0x00 0x00 0x00	13.6%
							(2) RLE encoded	36.4%
							0x13 0x95 0x20 0x7 0x60 0x42 0x1b 0x20 0x50 0x41 0x28 0x6 0x60 0x9e	−5.3%
							(3) BWT+RLE
Custom protocol implementation
Button #1 key event press (1)	t	t	t	t	x	crc8	Compared to standard formats, binary representation is much more compact.	−68.4% (compared with plain JSON)
	68	20	37	0b	11	6c
Button #2 key event press (3)	t	t	t	t	x	crc5	It requires only 4 bytes for the timestamp and 1 or 2 bytes for the event information (suitable for simple events is a single byte, where 4 bits are used to identify the event type and another 4 for its source.	−57.1% (compared to BSON)
	68	20	37	0b	21	Fc

With that approach it is essential to provide a method for time synchronization between receiving units (which on their own can sync time over NTP) and the beacons. We followed the approach recommended in [14]. It is also possible to decided on other serialization method and data format (with additional details available in [15,16]), although for making use of other available tools we have decided to use the most commonly supported alternatives.

-

For long-running processes, the time count is not seconds but minutes or even larger periods.

Of course, a combination of both can be applied, depending on the specific application, with the cost of this optimization being the need for data-receiving units to perform additional timestamp conversions before forwarding the data or storing it locally. Performing this conversion on every received and optimized packet also resolves the problem of changes to the whole system being made and this special interval/offset being updated. To distinguish between tokens that rely on optimized timestamps and those that use standard ones, the payload JSON uses various identifiers—“t” for standard 4-byte, second-based times and “T” for custom units, and so forth.

We also tested an implementation with the custom binary protocol, which allows for a much more compact representation of the data; thus, even when using a checkum like CRC8, it is possible to fit more (up to five) events into a single packet. One disadvantage of this option is that it requires custom adapter/processing which pays off for complex events.

With regard to time synchronization, it is possible to do this by broadcasting time information at regular intervals (a task performed by repeaters and gateways—as they are normally constantly powered—that does not impose any additional power budget restrictions). Smart beacons on the other hand can listen for such time sync messages only on certain occasions and for short periods (for example, only in the case that there has been no event over several hours which would indicate a shift end or maintenance period, or when the timer is expected to overflow anyway)—this approach would also minimize the energy required to handle time synchronization.

Once events have been received and preprocessed by the repeater/gateway devices, they are forwarded for further storage and analysis, which in this case is performed with simple statistical and machine learning scripts, implemented in Python 3.11 and visualized with Grafana 11.6.3. Typically the amount of event processing algorithms that can be applied depends on the type of event data collected, but for typical business process optimization, we identified that even the simplest pieces of information like timestamps and event sources (specified by the producing device identifier or optionally a button press) are sufficient to estimate processing step lengths or deviations and to proactively detect issues (for example, by checking for lack of inputs over certain threshold).

The use of standard data formats and types (JSON) makes it possible to quickly exchange the analytical and visualization software without building special adapters or modifying the firmware of the gateway devices and beacons.

3. Results

Our experiments demonstrate that formatting the data in BSON makes it possible to reduce the transmission time by more than 40% compared to the JSON equivalent. It also makes it possible to pack in more data from external sensors like temperature and humidity, which can be used to better monitor the working environment.

In addition to the payload of the individual beacons (limited to 31 bytes), repeaters rely on the signal strengths of individual beacons (calculated in RSSI and or AoA, depending on the hardware configuration) to provide the rough positioning of individual devices. Although this approach is not accurate, in situations with more than one repeater, combined information may be used to track down individual BLE devices with greater precision. This provides yet another useful input for capturing process efficiency, as it is possible to calculate movement speed and individual stages, even without manually provided signals.

We have also been able to identify two major hurdles in implementing the beacons in an industrial environment, which influence their application and firmware features.

The choice to use JSON/BSON as the data protocol absolutely lacks efficiency in terms of the used space. However, it was selected due to the single advantage that it is commonly recognized by a large number of tools and makes it possible to integrate beacons with existing systems without implementing special protocol adapters. More compact data transmission can be achieved with the use of a custom binary protocol with fixed offsets for timestamps and event information, combined with a small parser at the receiver device. We have highlighted some of the experiment results along with limitations observed in

Table 2. Discovered limitations during the test implementation.

Limitation	Experimental Results	Remarks
Transmission power and estimated reliable communication distance are lower than expected	With the typical range in clear space of a beacon being up to 30 m, it was discovered that in industrial environments this effective range is up to 2–2.5 m in some special cases with a lot of metal obstacles.	As a mitigation measure, we identified 3 steps: (a) increasing the transmitting power, which results in the faster drain of the battery; (b) mounting repeaters on the rooftop as that allows for better communication; and (c) implementing a more robust event protocol.
Timing synchronization	When beacons are allowed to collect and transmit data in chunks, timing synchronization is turned into a barrier for further proper synchronization.	As a countermeasure, we implemented a very simple time synchronization protocol.

. Various mitigation steps have been taken to relax the limitations, which have proven to be sufficient for simple business process data collection and analysis.

While implementation details are important and impose limits on what can be achieved with the system, the important output from the conducted experimental implementation is that even very simple and low-cost technical solutions can be of great help in gathering information on production processes and the collected inputs can be used to analyze ongoing tasks and optimize their management and execution. This is particularly important for small companies that are often not able to benefit from sophisticated external consultancy services or expensive business process optimization tools. As the suggested approach is very flexible and the individual meaning of events can be assigned depending on the studied processes, BLE beacons, either completely passively sending data or in combination with simple interaction options, can be (re)used in various business scenarios.