Field Research Cooperative Wearable Systems: Challenges in Requirements, Design and Validation

Abstract

The widespread availability of wearable devices is evolving them into cooperative systems. Communication and distribution aspects such as the Internet of Things, Wireless Body Area Networks, and Local Wireless Networks provide the means to develop multi-device platforms. Nevertheless, the field research environment presents a specific feature set, which increases the difficulty in the adoption of this technology. In this text, we review the main aspects of Field Research Gears and Wearable Devices. This review is made aiming to understand how to create cooperative systems based on wearable devices directed to the Field Research Context. For a better understanding, we developed a case study in which we propose a cooperative system architecture and provide validation aspects. For this matter, we provide an overview of a previous device architecture and study an integration proposal.

1. Introduction

Wearable devices are trending topics in different areas such as healthcare and activity recognition [1,2,3,4,5,6,7], sports [8,9], education [10,11], industry [12,13], human–computer interaction [14] and other areas. The rise of new concepts like the Internet of Things (IoT) [15,16,17] and Industry 4.0 [18] along with hardware miniaturization allow for the development of novel devices and solutions. Furthermore, the communication aspect on wearable systems is an important aspect on novel developed solutions [19,20].

Before studying the concepts involved in Field Research Cooperative Wearable Devices, it is crucial to understand the most significant features of this area. In addition, it is necessary to provide an overview of how wearable solutions are used in the studied context. Finally, we also need to present this work’s scope, objectives, and contributions.

1.1. Wearable Devices

An initial definition about the wearable device concept, provided by Rhodes [21], states that these elements are computers that are with the user all the time. Rhodes still affirms that wearable devices are portable while operating, and usable without blocking the hands. According to him, these devices have sensors, gather, and treat data even in a passive state, besides being always active and running.

Another feasible definition for wearable devices, presented by Bonato et al. [22], is that they are non-obtrusive devices. In other words, wearable equipment cannot obstruct the user’s movements during usage. Furthermore, Billinghurst and Starner [23] state that wearable systems must satisfy three different objectives:

• They must present mobility;
• They must augment reality;
• They must add context-awareness.

Pascoe [24] states that wearable devices’ context-awareness comes from embedded sensors. These gadgets should gather data, adapt, find resources, and augment reality. Wei et al. [25] discuss that, in modern approaches, these elements also have connectivity. For instance, this allows the integration with applications using cloud computing and an intersection with the IoT.

1.2. Cases of Use: Outdoors and Field Research Wearable Devices

In the last subsection, we presented wearable devices’ principal concepts. Here, we provide an overview of the propositions and use cases from field research applications found in the literature. This information is essential to understand the features and validation processes applied to these solutions and how they will further relate to our case-study.

Delabrida et al. [26] developed a Head-Up Display (HUD) to provide useful information in ecological field research processes. Their solution aims to help geologists in some of their in-field measurement activities. In addition, their solution monitors environmental safety information, such as weather conditions. To validate their appliance, they tested the algorithm accuracy and system performance with different boards.

Silva et al. [27] developed a Smart-Helmet for field research processes in ecology. Their device objective is to help ecologists performing canopy studies on the forest environment. To do so, they collect distance information, orientation, and images from the environment. They validate their appliance testing the energy consumption, sensors’ data quality, and transmission quality.

Silva et al. [28] also evolved their Smart-Helmet solution for field research in ecology. Again, this solution aims to help ecologists performing forest canopy studies. To validate their system, they provided a validation routine for their data-fusion and augmented reality algorithm.

Biremboin et al. [29] present a system based on commercial off-the-shelf wearable devices to monitor the user’s mental state. With this solution, they aim to monitor the user during outdoor activities. To validate their system, they performed a test with different users walking in a predefined outdoor route in Utrecht, the Netherlands.

Delabrida et al. [30] proposed a wearable system for 3D data acquisition and environment reconstruction. This proposal also aims to help ecologists performing canopy studies, reproducing the forest in a virtual environment. Their proposal presents the main architectural features and identifies the most critical flaw sources. Nevertheless, they do not use a formal practical validation process.

Delabrida et al. [31] developed a Head-Mounted Display (HMD) to help geologists. This proposal aims to help these researchers in common in-field measurement activities, providing a visualization using Augmented Reality. To validate aspects of this solution, they performed an Operating Systems (OS) evaluation, an algorithm performance evaluation, cross-platform hardware evaluation, and an energy consumption evaluation.

Chen et al. [32] presented a wearable device to detect heat strokes. This solution uses sensors to detect body temperature, heart rate, GPS location, and environmental conditions to determine the risk of heatstroke. To validate their system, they developed an experimental condition in which they measured vital signals of a male subject with the proposed prototype.

Velazquez et al. [33] propose a novel wearable device to aid visually impaired users in outdoor navigation. Their tool uses GPS and tactile feedback signs to help to indicate directions in the user’s shoe. They validated their prototype with early tests of the system performance.

These research works propose and validate devices or systems applied in field research or outdoor environments. Moreover, they target health hazards, dangerous activities, or difficulties due to impairments. In every case, they examine their case of use analyzing pieces of information about the process. Afterwards, these researchers propose devices or systems to extract the information based on wearable sensors and even provide some feedback to the user. Finally, most of them validate their systems using tests based on the identified system requirements.

1.3. Objective

In the last two subsections, we presented the concepts around wearable devices and systems. In addition, we displayed some use cases where these concepts apply in field research. In the former subsection, we mainly analyzed how the area researchers proposed and validated systems based on wearable devices in different appliances and concepts. Here, we explain the main objectives of this work.

In a first analysis, we could not find the usage of cooperative wearable systems in field research. Although some of the research present devices with distributed computer nodes working in cooperation, none of them explore the integration of multiple wearable devices in this context. Thus, this work has the following main objective:

• A study of the challenges in the requirement establishment, design, and validation processes for Field Research Cooperative Wearable Systems.

We perform this study through two steps. The first one is a theoretical approach, reviewing the state-of-the-art articles on the area, and presenting how the researchers systematically approach the requirement definition, design process, and validation. The second one is a practical case-study, in which we apply this systematical approach to validate and analyze these methods.

In the first stage, we overview the requirement establishment and design process for Field Research Cooperative Wearable Systems. From our presented review, we understand that this perspective adds flexibility and modularity to wearable systems design. In addition, we present a general approach to the design and validation method applied by the researchers in the latest articles found in the literature.

In the second stage, we also want to validate the requirement establishment and design process through a case-study. This validation follows the reviewed and presented methods. For this matter, we develop a platform based on a previously verified platform, proposed by Amorim et al. [34]. This process focuses on the design of a novel system architecture using validated devices to the detriment of novel device architecture. This proposal follows an organization called the Multiple-User Cooperative Wearable System.

1.4. Contributions

In this paper, we provide two main stages to approach the main objective. The first one is a theoretical analysis of the requirements, design aspects and possible architectures for Cooperative Wearable Systems and field research devices. The second one is a case-study using the theoretical review to approach a solution. Thus, we summarize our main contributions as:

• A theoretical analysis of the requirement establishment process of field research gear;
• A theoretical approach to the wearable system design process stages;
• A conceptualization from Cooperative Wearable Systems (CWS), especially applied to the field research context (FR-CWS);
• A case-study validation using the Multiple-User Cooperative Wearable Systems concepts, with:

  -

  A context overview, containing some related applications;

  -

  A requirement estimation based on the context analysis and regarding the challenges identified in the theoretical overview;

  -

  A novel FR-CWS architecture proposal, considering the information gathered on the conceptualization stage;

  -

  A formal validation testbed, considering ground aspects from this kind of device;

• A discussion, formalizing the main challenges identified through both stages.

1.5. Text Organization

For the proposed matter, Section 1 introduces the concepts of wearable devices and presents some cases of use in outdoor and field applications. In Section 2, we define the boundaries of field research gear and how to establish their requirements. Furthermore, we overview the wearable systems design process and conceptualize Cooperative Wearable Systems. Section 3 presents this text’s case study steps. It introduces the requirements, device architecture, system architecture, evaluation methods, and results. Finally, we discuss the obtained theoretical and practical results in Section 4.

2. Conceptualization

In the previous section, we presented the main concepts around wearable devices, as well as some of the applications in similar contexts to this work. This section presents an overview and helps to create the main concepts around Field Research Cooperative Wearable Systems (FR-CWS). At first, we need to understand the requirements of field research equipment. Afterwards, we need to overview aspects of wearable systems design. Furthermore, we need to review existing cooperative wearable systems, understanding the involved technologies and concepts.

2.1. Field Research Equipment Requirements

An essential stage in any field research is the equipment selection. Nevertheless, this task is not simple. For instance, Shapira and Goldberg [35] affirm that this is a key factor for the success of a construction project. In addition, Zaneldin and Sivaloganathan [36] state that the process of selecting suitable equipment in this context is essential in heavy industrial processes.

Similarly, every field research process has its occupational hazards. Yilmaz Kaya and Dağdeviren [37] affirm that the equipment selection may follow a universal design (UD) pattern. The UD principles are:

• Equitable Use;
• Flexibility;
• Simple and intuitive use;
• Provide perceptible information;
• Error Tolerance;
• Low physical effort;
• Appropriate dimensions.

In [35,37], the researchers also state that the safety equipment selection follows an analytic hierarchic process (AHP). This process identifies the main targeted problem, along with its factors and subfactors.

Therefore, when proposing novel wearable solutions for field research with occupational hazards, a suitable outcome is to adapt new functionalities onto previously selected gear, and then to implement and try to adopt different external modules. This process follows both the UD pattern principles without the need for new AHPs.

2.2. Wearable Systems Design

The wearables creation process commonly goes through a set of steps aimed at defining each of their internal components, whether related to hardware or software. It is common that, during the process of building these devices, their organization/architecture will be approached at some point, commonly in the early stages. Often, each new device being developed eventually restarts the creation process that goes through all the steps again, without reusing any already created part.

Then, creating wearable devices that can be reused requires standardizing the whole construction process. These hardware and software components’ organization/architecture standardization is an early and necessary stage in the wearable devices’ development process. A standardization may pave the way to potentially reuse the same solution in a variety of applications context. This subsection presents a proposed methodology for building wearable prototypes/products. Steps presented in this process can be thoroughly carried out “as is”, or have some parts modified/removed as a way to comply with the desired specification.

The last subsection presented design aspects and the equipment selection process for field research tasks. This section presents an analysis of some factors of the wearable devices design process and general methodology. This is important to understand the most relevant variables when proposing novel tools and architectures. This paper analyzes hardware and software project practices and the usual methodologies employed during the design process of wearable systems [34].

A general analysis of wearable devices design process can proceed considering the two main macroblocks: hardware and software parts. However, there is a common core that runs through both contexts. Figure 1 presents a general overview of common steps usually taken into consideration when developing wearables research. It also covers standard context blocks and specific ones related to software or hardware parts. Additionally, it is also outlined that hardware and software designs share specific modules:

• Requirements definition: Step of requirements gathering through the final application context analysis. Data collected here influence the whole process until the wearable solution deployment; and
• General architecture proposal: Requirements work as inputs to create a general architecture, enclosing hardware and software parts. The architecture proposal also allows for figuring out how hardware and software parts will communicate with each other.

However, besides these two initial modules, there are specific parts that will be carried out only in one of these contexts of development.

• Hardware: Commonly used methodology to plan, design and build the wearable prototype hardware part.

  -

  Hardware components selection: After requirements and architecture definition, it is possible to enumerate the necessary hardware components/modules that will support the desired features;

  -

  Prototype planning and design: Hardware components serve as input data to plan and design the final prototype. In this step, components connections are defined, and Printed Circuit Boards (PCB) layout is outlined, if necessary;

  -

  Prototype development: This part will carry out wearable device manufacturing. Main Central Processing Unit (CPU) and hardware peripheral components will be physically connected, possibly using a final version of PCBs designed in the previous step. In the end, components can be attached to the garment; and

  -

  Device tests/validation: Several rounds of in-place hardware tests and validation to verify the connections made with each component. If this part does not work as specified or pass the validation tests, specific points can be fixed/changed in a new development round.

• Software: Considered methodology when developing a wearable prototype associated software solution.

  -

  Software design: The previously specified requirements can also be used as a reference to design the related software. This step involves functionalities definition, as well as the planning of how inner modules will interact with each other;

  -

  Software implementation: Design planned before may now be used as a reference to properly code the software. Commonly, specific and lightweight programming languages/frameworks can be used here, according to the whole solution needs;

  -

  Software tests/validation: This module is in charge to test and check if the resulting software is compliant with previously specified requirements. If the solution does not fulfill the requirements (or does not pass the validation tests), a new development round can be carried out.

The remaining blocks are used by both contexts:

• Hardware/software integration: This part encloses the integration of previously developed hardware and software parts. This is a mandatory step, once both of these parts were independently developed until here. Basic and composed functionalities can be evaluated, verifying whether they provide the expected output or not; and
• In-field deployment/validation: This is the final step of wearable systems design. The wearable device, which now has integrated hardware and software modules, are deployed and validated during in-field sessions. This occasion is also used in several research projects as the moment to gather and retrieve empirical data.

The design process shown here is sometimes also used with some additions. The research presented by Liang et al. [38] extends the diagram presented in Figure 1, adding a new software part in a cloud-centered infrastructure. Indeed, Lim et al. [39] address the system design and development in a simplified way. Despite this simplification, all elements presented here are still available in this research.

2.3. Cooperative Wearable Systems

After comprehending the design process for wearable devices, we also need to understand how wearable devices and systems are used in cooperative systems and environments. Zheng et al. [40] reaffirm that this integration brings innovations to different areas such as healthcare, sports, entertainment, and others. In some cases, the acquired data can even be integrated into cloud applications, as presented by Fortino et al. [41]. Thus, it is also vital to understand the architecture proposal and validation processes.

Xu et al. [42] state that wearable devices produce a large amount of information, which can provide useful resources for external algorithms that process this data. Ometov et al. [43] enforce the idea that cooperative wearable applications have some design challenges, especially related to heterogeneous communication and offloaded computation. In addition, Zhang et al. [44] affirm that communication delays are also a cost factor in IoT cooperative networks. They enforce that minimizing energy and delay costs is crucial in this context. Furthermore, an optimization method as the one proposed by these researchers helps to identify sensed events and even cooperative decisions in architectures as the ones evaluated in this work.

Augimeri et al. [45] and Fortino et al. [46] present four different conjectures for collaborative body sensors. In two of them, the data gathered from a single user provide data to one or multiple stations. In the other two, data gathered from multiple users feeds one or multiple stations. Similarly, to understand the ways to cooperate using wearable devices, we categorize the Cooperative Wearable Systems into two scenarios:

• Single-User Cooperative Wearable Systems,
• Multiple-User Cooperative Wearable Systems.

The first type happens when the same user utilizes multiple wearable devices to compose a system, feeding one or multiple applications in base stations. The second type occurs when many users wear the same equipment, with post-processed data and flexibility gained in the final appliances in individual or various consumer stations.

2.3.1. Single-User Cooperative Wearable Systems

Wearable compositions are important to monitor the context of the environment and also the user. Mihovska and Sarkar [47] introduce an important concept for this context: Human-Centric Sensing. According to these researchers, the IoT and connectivity of modern devices provide the tools to create cooperative systems around the user. These appliances can monitor both user signs and the surrounding environment.

Zhang et al. [48] proposed a cooperative environment based on a glove-shaped pressure sensor and an armband. This system was designed to provide gesture recognition for Human–Computer Interaction devices. To validate this system, they performed a set of tests to verify the recognition accuracy.

Peng and Peng [49] affirm that Body-Area Networks became an important tool to create novel healthcare solutions with collaborative wearable devices. They proposed a cooperative communication strategy to integrate multiple devices in a Wireless Body-Area Network (WBAN). They validated their proposal using simulations.

Nguyen-Huu et al. [50] present a combination of a wearable device and smartphone working in cooperation to monitor daily activities in an indoor environment. Their system uses both an armband and a smartphone to gather sensor data, process and recognize activities, and transmit this information to a web server for further analysis. They validated their system using performance evaluations on their activity recognition and lifelogging algorithms.

Most of the proposed systems and architectures use wearable devices as IoT nodes in a Wireless Body-Area Network. In some situations, they also employ smartphones as connection gateways. Finally, these works follow the same systematical process, starting with requirement analysis, architecture proposal, implementation, and validation.

2.3.2. Multiple-User Cooperative Wearable Systems

Pimentel et al. [51] present a multiple-wearable cooperation system for monitoring the stress of multiple surgeons. They use commercial devices for vital signs monitoring, gathering ECG and actigraphy signals. An Android Application gathers the data from the wearable devices, marks events, creates reports, and stores this data in a database. Finally, they used several statistical studies to validate the self-assessment tools present in the Android application.

Prakash and Ganesh [52] established a wearable-based communication environment for cooperative health monitoring in hospitals. They interpret this environment as a Wireless Sensor Network (WSN). To validate this environment, they used network simulator applications and verified the packet transmission performance.

Pham et al. [53] present and validate a wearable-based system environment to monitor older adults and patients with Parkinson’s disease. They propose an architecture based on IoT wearable devices with Inertial Measurement Units (IMUs) located on the user’s lower limb. From the data of this device, the system tries to recognize postural transitions. To validate this proposal, they tested their environment and system with actual target users with Parkinson’s Disease and older adults, and compared the results with video recognition, using statistical analysis.

Even in a multiple-user context, the state-of-the-art works follow the same systematical process in the systems proposal. They analyze the context of use and gather the system requirements, propose an architecture, assemble a prototype environment to test their proposal, and perform validation tests.

3. Case Study

In Section 1, we presented the definitions around wearable devices and their cases of use in field research. In Section 2, we built and reviewed the concepts encompassing Field Research Cooperative Wearable Systems (FR-CWS). For this matter, we understood the requirement verification and design processes, proposing the concept of Cooperative Wearable Systems (CWS).

In this section, we perform a case-study to validate the presented processes. This system is based on a prototype proposed by Amorim et al. [34], displayed in Figure 2. We do not propose any change in the hardware configuration since our objective here is not to validate the device alone, but the application of multiple devices. All sensors were previously used side-by-side, and tested during the prototype development stage.

We explore the fact that this solution was previously proposed and validated. As presented in Section 2.1, the proposal of novel devices requires a systematic process. For this matter, we follow the concept of Multiple-User Cooperative Wearable Systems, presented in Section 2.3.2, exploring the usage of the same device in different applications.

Hence, we use the knowledge of the present sensors to describe novel applications that can use this data to generate new information. This study analyzes the evolution of this system towards a CWS, and, more specifically, a FR-CWS. This process follows the observed methods for the proposal and validation of wearable devices and systems. Furthermore, we create a conjecture in which this system can attend different appliances.

3.1. Context Overview

This subsection presents the context in which we apply the proposed solution. First, our wearable device collects useful information from the user and the surrounding environment. At first, this wearable was designed to support workers in open-sky mining industry [34]. Thus, this work considers a broader hypothetical scenario in forest field research. It was created based on usual tasks from wearable devices and field research. In such a scenario, a multidisciplinary team gathers different information from the device. The members of this team are:

• A medic, monitoring the team’s health [54,55];
• A biologist/ecologist, measuring sensor values for his research [56,57,58];
• A physiologist, studying the physical effort in each kind of task [59,60,61];
• A navigator, cross-checking the global position with physical or virtual maps [33,62,63].

Each of the members of this group wears the same safety field research gear and has access to the data of the whole team gear. In addition, each member has access to a Smartphone app with specifically-designed features to their professional functions. This architecture seeks to use the flexibility of the device produced data to attend different subjects with the same wearable, as a characteristic of multiple-user CWS.

3.2. Requirements

This subsection presents an overview of the requirements for the context of this wearable system. The first set of specifications come from the wearable devices common features:

• The device must not block the user’s common movements;
• It must provide information from sensors;
• It must detect context changes.

Furthermore, as presented in Section 2, the adoption of new devices in field research require the creation of novel AHPs. Thus, it is better to adapt the wearable system into common-use safety gear. The adoption of these devices prevents the process of implanting a new safety device. Hence, as a case study, we chose a safety vest as the baseline from our proposed solution.

Henceforth, the team will be identified as M for the medic, E for the Ecologist, P for the Physiologist and N for the navigator. For the demands of the multidisciplinary team, this device must have sensors which provide:

• Body temperature and humidity (M, P);
• Heart rate and blood oxygenation (M, P);
• Environmental luminosity, temperature and humidity (M, P, E);
• Global Position and Altitude (E, N);
• Muscular Effort (P);
• Body Motion (M, P);
• Safety lights (M, E, N, P).

Each professional can obtain the required information from all the crew members, in an application designed with the specifications from each of them. This feature comes with the flexibility of CWS.

3.3. Device Architecture Description

In the last subsection, we presented the requirements for the proposed CWS. In this subsection, we present the architecture and features of the prototype applied in this context. Figure 3 represents the main elements of this prototype.

As mentioned, this device was previously presented by Amorim et al. [34]. It has sensors to monitor both the user and some environmental variables. These sensors are:

• User Sensors:

  -

  Temperature/Humidity Sensor—This sensor monitors the temperature and humidity internally. This sensor connects reading digital data from a GPIO pin;

  -

  IMU Sensor—This sensor monitors the user’s body motion. It communicates using the I2C bus;

  -

  EMG Sensor—This sensor monitors the muscular effort from the user. It transmits the measured data using GPIO monitoring;

  -

  ECG Sensor—This sensor monitors the heart rate and blood oxygenation. It communicates using the I2C bus.

• Environmental Sensors:

  -

  Temperature/Humidity Sensor—This sensor monitors the temperature and humidity externally. This sensor connects reading digital data from a GPIO pin;

  -

  GPS Sensor—This sensor gathers the global position data and transmits it to the computer board through the MCU. The MCU uses a serial connection to communicate with this board;

  -

  Luminosity Sensor - This sensor gathers luminosity data and transmits it to the computer board through the MCU. The MCU uses I2C connection to communicate with this sensor.

Furthermore, the vest provides the option of actuation. The MCU can use the luminosity sensor to activate safety lights in case it detects a dark environment. For a better understanding of the organization of this device sensors, Figure 4 presents an illustration of the components’ geometrical location. As presented at the beginning of this section, this device was previously tested and validated in [34]. All of the elements fit on a safety vest and don’t block or bother the user.

For a broader comprehension of the system’s capabilities, it is also important to map the data acquisition time for each sensor. This information also helps to create the simulated devices in the validation stage. For this matter, we summarized the acquisition time for each sensor present in the prototype developed by Amorim et al. [34].

Table 1. Sampling time ratio for each sensor.

	Variable	Sensor	Sampling Time
User	Temperature and Humidity	AM2302 (DHT22) [64]	2 s
	IMU	MPU6050 [65]	0.125 ms
	EMG	Myoware	System Sampling Rate [66] (∼5 µs)
	ECG	MAX30100 [67]	1 ms
Environmental	Temperature and Humidity	AM2302 (DHT22) [64]	2 s
	GPS	FGPMMOPA6H [68]	0.1 s
	Luminosity	TSL2561 [69]	2.5 µs

presents this summary. In addition, we consider that the consuming applications will further post-process the sensors acquired data. Therefore, the presented sampling times consider the smallest interval required to acquire this minimal information.

This analysis used the provided information from the sensors and the computer-on-chip datasheets [64,65,66,67,68,69]. Finally, we consider that all sensors were properly calibrated in a previous assembly stage with the correct methods. For a broader comprehension, we also present the general characteristic of the calibration process for each sensor. The AM2302 sensor needs a chemical process in a closed chamber for calibration, as it is an hygrometer–thermometer [70]. The MPU-6050 is a 6-DoF IMU, which requires a 3-axis motion and spinning movements [71]. As an EMG sensor, Myoware must be calibrated before the usage, considering reference levels of contraction signals [72]. As a GPS module, FGPMMOPA6H requires a factory calibration according to its antenna [73]. TSL2561 is a lux meter, and therefore must also be previously calibrated with its response curve [74]. Finally, MAX30100 is a pulse-oximeter, and thus requires factory calibration with the light wavelength response [75].

3.4. System Architecture

In the last subsection, we presented the main features of the wearable devices which will compose this system. In this subsection, we present the proposed CWS architecture. We based the architecture in the multidisciplinary team presented in Section 3.1. As mentioned, the crew is composed by a medic (M), an ecologist (E), a physiologist (P), and a navigator (N).

This system follows the concept of Multiple-User CWS, defined in Section 2. Within this context, multiple users wear the same device. The flexibility gain happens in the application level, where the data collected from the wearable devices will be post-processed.

Figure 5 represents the CWS architecture integration. As mentioned, each crew member has an application to gather the sensors’ data using wireless communication protocols. From the complete data, the applications separate useful information for each professional involved in the process.

In modern applications, wearable devices can be interpreted as IoT-nodes [76,77,78,79,80,81]. Thus, in the context of this work, each wearable is also modeled as an IoT-node composing a FR-CWS architecture. Each member of the crew can use a smartphone connected to the network or to a gateway to query the data from each wearable device.

Each crew member application has a proper sampling interval need, according to each professional specialty. Nonetheless, this sampling rate must consider the sensor reading interval and communication latency, natural in this kind of system. Before moving forward, it is also important to understand the communication options for composing a wireless network. Mahmoud and Mohamad [82] divide the network protocols for the IoT according to the communication range, following this nomenclature:

• Proximity (up to 10 m);
• Wireless Personal Area Network (WPAN) (up to 100 m);
• Wireless Local Area Network (WLAN) (Up to 1000 m);
• Wireless Neighborhood Area Network (WNAN) (up to 10 km);
• Wireless Wide Area Network (WWAN) (up to 100 km).

According to the conjectured scenario, we desire that the users have access to each other data in distances within the ranges of WLAN and WPAN. For this matter, this work also provides some examples of technologies in use in these scenarios.

Table 2. WPAN and WLAN connectivity technologies.

	Range	Technologies
WPAN	up to 100 m	blacktooth LE, ZigBee, Thread (6LoWPAM), Z-Wave, ANT+, WirelessHART, ISA100.11a (6LoWPAM), EnOcean, …
WLAN	up to 1000 m	802.11a/b/n/ac, 802.11af, 802.11ah & 802.11p

presents these options.

In a test scenario, we use the WLAN as connection mean, as it is enough to manage the information exchange for a crew working in proximity.

3.5. Evaluation Methods

As the proposed system is a distributed device network, an important aspect of the architecture is its communication restraints. To validate this solution as a cooperative multiple-node system, we need to analyze the feasibility of the proposed system. In addition, we need to understand the limitations of the data availability in this network before any algorithmic proposal. Thus, for this evaluation, we define a mathematical model based on Quality-of-Service (QoS), like the ones presented by Boukerche and Samarah [83] and Silva and Oliveira [84]. This QoS test evaluates the information availability, providing the temporal constraints that must be evaluated when creating consuming applications.

At first, we assume that the transmission time is divided in equally-sized timeslots, represented by the set $T=\{t_1,t_2,t_3,\dots ,t_m\}$, where $t_{i+1}-t_i=\lambda$ for $1<i\le m$.

Definition 1.

Let $D=\{d_1,d_2,d_3,\dots ,d_n\}$ be the set of n wearable devices present in the network.

Definition 2.

Let $p_j=d_r\dots d_s$ be a data acquisition pattern, where each $d_i$ element is a device from D ($d_i\in D$).

Definition 3.

Let $P=\{p_1,p_2,p_3,\dots ,p_k\}$ be a set of k desired observation patterns.

Definition 4.

Let $F(p_a,x)$ be the number of observations of a $p_a$ pattern within an x number of timeslots.

Definition 5.

Let $F(p_a)$ be the total number of observations of a $p_a$ pattern in the whole test period.

The quality parameter $Q_s(p_i,k)$ for a pattern $p_i\in P$ expected in a k number of timeslots is defined by the following equation:

$$Q_s(p_i,k)=\frac{F(p_i,k)}{F(p_i)}.$$

(1)

In our scenario, each wearable will be simulated using a Raspberry Pi Zero W computer-on-chip connected to the network. These devices were chosen as they were the main hardware nodes in the initial prototype developed by Amorim et al. [34].

In every possible scenario, the professionals may want to receive the messages from one member, two members, three members or the whole crew. If we consider our pattern set P defined by all the permutations of arrangements from the elements of D according to this rule, our complete pattern set has a size S of:

$$\begin{array}{c}S=P(4,1)+P(4,2)+P(4,3)+P(4,4),\hfill \\ S=\frac{4!}{3!}+\frac{4!}{2!}+\frac{4!}{1!}+\frac{4!}{0!},\hfill \\ S=64.\hfill \end{array}$$

Thus, for each possible combination of P, we performed 30 tests for each device running in parallel, trying to obtain the same data. On each test, the consumer applications concurrently try to retrieve the data from each sensor according to the possible message patterns of P. Each consumer application is generated as a generic client in the network, with the capability of establishing a connection with each node through the network gateway and querying its sensor data. In addition, in each test, the consumer applications will try to gather the same data. Finally, the wearable devices will be available during the whole process, as a wearable and IoT requirement.

After running the tests, we analyze the data to check the quality factors defined according to the timing requirements presented in Section 3.4. For simulation purposes, the string containing the simulated data will be released after an interval of 4.2 s.

3.6. Results

In the last subsection, we presented the validation test set for the proposed case-study. Here, we analyze the created modules and practical aspects of the realized tests. The proposed test set is a simulation of the actual network environment. For this matter, we developed a server application in four different computer-on-chip nodes, connected to a WLAN network, as mentioned in Section 3.5. In addition, we configured four different computers as clients to query data from the server nodes.

The client nodes can perform one query at a time. This avoids one application to block the sensor nodes after connecting. As mentioned above, each client application runs the same code, as well as each sensor node executing the same server routine. The devices are distributed in the local wireless network as presented in Figure 5.

In Section 3.5, we also mentioned that the test covers each message scenario of possible queries. The evaluation method considers the Equation (1), presenting the quality factor for a time window of k-timeslots. As presented in Table 1 and Section 3.5, the total time to obtain the data from all sensors is around 4.2 s. Thus, we decided to analyze the discrete-time slots in intervals of $\lambda =1$ s. In addition, the quality factor must consider the number of queries in a pattern, as each query will take at least five timeslots to be solved. Therefore, after deciding the k factor, the analysis uses the following equation to calculate the actual $k_l$ factor, where n is the number of queries in the $p_j$ pattern, $p_j\in P$:

$$k_l=n.k.$$

In addition, as presented before, there are a total of 64 unique patterns considering the single combinations of each $d_i$ device, $d_i\in D$. Therefore, we collected the times for obtaining each pattern $p_j\in P$ composed of a unique combination of devices.

All four client devices repeated this procedure 30 times, executing in parallel and concurrently querying data from the server nodes. Finally, we analyzed the data considering different k values, starting with $k=5$. Figure 6 displays the obtained results from the tests.

The objective of this analysis is also to understand the constraints of the proposed architecture and its elements. The QoS factor is a fraction of the total observations of a pattern. Therefore, we present the results as percentages.

The results of the QoS tests indicate that the minimum number of timeslots to guarantee the complete delivery of patterns is nine slots, or in other words, nine seconds. As mentioned, the minimum number of slots necessary to generate and transmit the data are five. Thus, the applications of each research must consider using acquisition rates between 5 and 9 seconds per device.

The results show that the average QoS factor for $k=5$ is 77.8%. The average QoS factor for $k=6$ is 95.0%. The average QoS factor for $k=7$ is 99.4%. The average QoS factor for $k=8$ is 99.9%. The quality factor is 100% for $k=9$. As expected, the lower the value of k used in the analysis, the worse the quality factor result. This happens due to sensors’ acquisition latency and network concurrency. Figure 7 displays the average factor trend for each k value.

Another conclusion from this result is that the gain is small starting from $k=7$. Increasing the number of timeslots from $k=5$ to $k=6$ elevates the average quality factor by 17.1%. Increasing from $k=6$ to $k=7$ increases the quality factor in 4.4%. Increasing from $k=7$ to $k=8$ raises the quality factor only by 0.5%. Finally, increasing from $k=8$ to $k=9$ only elevates the quality factor by 0.1%.

The first conclusion with these test results is the validation of the network architecture. The test displays the capability of concurrently querying the wearable node devices for messages in an IoT-like application using wearable devices, even with the sensor reading expected latency. This result confirms the feasibility of the creation of a Field Research Cooperative Wearable System in the context of the case study. Furthermore, the creation of applications to consume the data from the wearable nodes should consider the timing constraints indicated by the QoS test. On average, the devices must plan to have an acquisition rate of around 7 s for each node. Finally, in the scope of this text, the usage of a 7 s acquisition rate guarantees a QoS factor of 99.4%.

4. Conclusions and Discussion

In this text, we presented both a theoretical and a practical analysis around Field Research Cooperative Wearable Systems (FR-CWS). At first, we presented the main context around wearable devices and some cases of use from wearable devices in Outdoor and Field Research applications.

In the following section, we reviewed and presented the main concepts of our theoretical analysis. We analyzed the requirement gathering process, as well as the wearable systems design procedure. Furthermore, we proposed the concept of Cooperative Wearable Systems (CWS), in single and multiple user applications.

The third main part of this work is a case-study method of designing and developing a cooperative wearable system for a field research appliance. We follow the design pattern proposed in Section 2, defining requirements, proposing an architecture and developing a Hardware and Software implementation to test aspects of the proposed architecture.

4.1. Requirements of Field Research Devices

In Section 2.1, we analyzed the main aspects around field research gear requirements. An important aspect of this matter is the definition of the correct equipment to use. This factor is vital to the success of the project. In addition, the gear selection must consider universal design principles and a hierarchic process. Thus, it is better to use the previously approved gear as a baseline to create novel solutions.

4.2. Design Aspects for Field Research Cooperative Wearable Systems

The wearable system design pattern follows a hardware and software co-design process. This procedure starts with the requirement definition for the problem, analyzing the solution context. From this stage, the creators propose a general architecture, segmenting the elements into hardware and software parts. These parts are designed in parallel and integrated into the main solution. Finally, the designers validate aspects of the proposed solutions with methodical tests.

4.3. Field Research Device Design and Validation

We applied the proposed methodical design pattern in a case-study. This task aims to analyze the proposed method in the context of a CWS, and more specifically in FR-CWS, where the constraints are firmer. This process also starts with a requirement gathering, considering information from the desired task. Starting from the Multiple-User CWS concept, this system proposes to use multiple versions of the same device to feed multiple applications with different objectives.

We started using the device proposed by Amorim et al. [34] as the baseline for our intended organization. The usage of previously validated devices as the wearable nodes evades the necessity of proposing a novel instrument before developing a cooperative environment. This also reinforces the re-use of verified gear, indicated in Section 2.1.

The analysis of the hardware present in the device allows for the estimation of sensor reading latency. This information has a crucial role in the availability of the data, as the devices behave as IoT nodes, responding to client queries. Thus, the proposed validation test targets the data availability before any device-wise or algorithmic estimation such as data-fusion or machine learning.

The proposed test set analyzes the data availability using a Quality-of-Service formalization for sensor nodes and cooperative wearable devices. This methodical approach allows a quantitative analysis of the system, approaching stronger validation results.

4.4. Challenges

In the last two subsections, we summarized the stages presented in this work. In this section, we systematically present the identified challenges in the Requirements, Design, and Validation of CWS. This is a qualitative analysis, which takes into consideration both theoretical and practical phases.

• Requirements:

  -

  The requirement establishment must follow UD patterns. This is a technical problem, as these design patterns follow a systematic evaluation process;

  -

  Safety equipment selection follows a systematic approach called AHP, which identify the targeted problem and its factors. The fulfillment of another systematic stage creates an additional technical challenge on the requirement establishment process;

  -

  CWS provides an extra set of requirements, especially from network and communication according to the target problem specifications. This issue exposes both technical and academic challenges, as working with state-of-the-art techniques and concepts.

• Design:

  -

  The requirements must precisely describe the proposal needs, since they work as inputs in the design process. This stage reflects on the quality of the presented solution after the validation processes;

  -

  The development of hardware and software modules must be parallel. Thus, they individually present technical challenges to systems developers;

  -

  The integration of independently developed Software and Hardware modules is a mandatory step, which needs to provide an expected result. This integration can expose technical flaws that came unnoticed in the previous stages.

• Validation:

  -

  After the design and development stages, the modules must be properly validated. Thus, this requires the establishment of a theoretical approach or the usage of a previous baseline. Within this context, the solution novelty presents challenges in both practical and theoretical approaches.

  -

  Many validation processes use prototypes as test mediums. This exposes the cost and time restrictions in the project development. This aspect is critical as both the academic results and the technical validations depend on the employed experimental set.

4.5. Final Considerations

The previous analysis validates both the theoretical and practical aspects of this work. The case study links the theoretical analysis to a practical aspect, allowing the observation of the proposed conjectures. Finally, this work fulfills its objects through these aspects—first analyzing the requirement establishment and design process for FR-CWS and then validating these processes through a case-study.