{'fraction_non_alphanumeric': 0.027669574053687866, 'fraction_numerical': 0.011177915149462274, 'mean_word_length': 4.9462487411883185, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 1, 'lorem ipsum': 0, 'www.': 1, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
P-Ergonomics Platform: Toward Precise, Pervasive, and Personalized Ergonomics using Wearable Sensors and Edge Computing

Preventive healthcare has attracted much attention recently. Improving people’s lifestyles and promoting a healthy diet and wellbeing are important, but the importance of work-related diseases should not be undermined. Musculoskeletal disorders (MSDs) are among the most common work-related health problems. Ergonomists already assess MSD risk factors and suggest changes in workplaces. However, existing methods are mainly based on visual observations, which have a relatively low reliability and cover only part of the workday. These suggestions concern the overall workplace and the organization of work, but rarely includes individuals’ work techniques. In this work, we propose a precise and pervasive ergonomic platform for continuous risk assessment. The system collects data from wearable sensors, which are synchronized and processed by a mobile computing layer, from which exposure statistics and risk assessments may be drawn, and finally, are stored at the server layer for further analyses at both individual and group levels. The platform also enables continuous feedback to the worker to support behavioral changes. The deployed cloud platform in Amazon Web Services instances showed sufficient system flexibility to affordably fulfill requirements of small to medium enterprises, while it is expandable for larger corporations. The system usability scale of 76.6 indicates an acceptable grade of usability.


Introduction
Musculoskeletal disorders (MSDs) are still common in the working population, causing individual suffering and an economic burden for companies and societies [1,2]. Further, the challenge of an aging population-an increased percentage of elderly individuals in the overall population-has occurred for more than two decades and its consequences, e.g., increasing costs, a lack of healthcare personnel, and more complex combinations of chronic diseases [3], have emerged. For economic reasons, a longer life expectancy requires an increase in the retirement age. These increases have already occurred in some countries and are planned in others [4,5].

Proposed Architecture
The system collects data generated by wearable sensors, processes it for the purposes of risk assessment, intervention, and evaluation, and delivers the data to different stakeholders, including the worker, coach, and manager. The proposed system architecture is illustrated in Figure 1. The system consists of three layers: a wearable sensing layer, a mobile computing layer, and a server layer. The wearable sensing layer provides various physiological and biomechanical measurements and preprocesses the raw signals. At the mobile computing layer, data from each sensor node is collected, synchronized, and processed into variables reflecting exposure. The risk levels are then assessed according to defined ergonomic criteria and real-time feedback can be sent to the individual for intervention. Data from each individual is collected and stored at the server layer, where further analyses at both individual and group levels occurs. The server layer also employs user management for data logging and information access.

Wearable Sensing System
The wearable sensor system consists of a t-shirt or vest, reported in other studies [19][20][21][22][23][24][25], which includes four textile electrodes made of conductive fabric. A pair of electrodes is used for the current injection and the other pair senses the electric potential. An ECGZ2 device (Z-Health Technologies AB, Borås, Sweden) was used as the recorder for electrocardiography (ECG) and electrical bioimpedance and was placed in a pocket on the shoulder strap of the vest or front of the t-shirt, as shown in Figure 2. ECG and thoracic impedance signals were recorded with sampling rates of 250 Hz and 100 Hz, respectively. One and two LPMS-B2 inertial measurement units (IMUs) (LP Research, Tokyo, Japan) were placed in the pocket on the back of the t-shirt or vest and t-shirt sleeves, respectively. The Polar A370 wristband smart watch (Polar Electro, Kempele, Finland) was included to monitor the daily activity and nightly sleep outside of working hours.

Wearable Sensing System
The wearable sensor system consists of a t-shirt or vest, reported in other studies [19][20][21][22][23][24][25], which includes four textile electrodes made of conductive fabric. A pair of electrodes is used for the current injection and the other pair senses the electric potential. An ECGZ2 device (Z-Health Technologies AB, Borås, Sweden) was used as the recorder for electrocardiography (ECG) and electrical bioimpedance and was placed in a pocket on the shoulder strap of the vest or front of the t-shirt, as shown in Figure 2. ECG and thoracic impedance signals were recorded with sampling rates of 250 Hz and 100 Hz, respectively. One and two LPMS-B2 inertial measurement units (IMUs) (LP Research, Tokyo, Japan) were placed in the pocket on the back of the t-shirt or vest and t-shirt sleeves, respectively. The Polar A370 wristband smart watch (Polar Electro, Kempele, Finland) was included to monitor the daily activity and nightly sleep outside of working hours.

Personal Analytics and Coaching App
Analysis of the data from the different wearable sensors and the provision of feedback to the user is done through different software layers. The software runs on an edge-computing node in the form of a smartphone device with an Android operation system. Figure 3 illustrates the different

Wearable Sensing System
The wearable sensor system consists of a t-shirt or vest, reported in other studies [19][20][21][22][23][24][25], which includes four textile electrodes made of conductive fabric. A pair of electrodes is used for the current injection and the other pair senses the electric potential. An ECGZ2 device (Z-Health Technologies AB, Borås, Sweden) was used as the recorder for electrocardiography (ECG) and electrical bioimpedance and was placed in a pocket on the shoulder strap of the vest or front of the t-shirt, as shown in Figure 2. ECG and thoracic impedance signals were recorded with sampling rates of 250 Hz and 100 Hz, respectively. One and two LPMS-B2 inertial measurement units (IMUs) (LP Research, Tokyo, Japan) were placed in the pocket on the back of the t-shirt or vest and t-shirt sleeves, respectively. The Polar A370 wristband smart watch (Polar Electro, Kempele, Finland) was included to monitor the daily activity and nightly sleep outside of working hours.

Personal Analytics and Coaching App
Analysis of the data from the different wearable sensors and the provision of feedback to the user is done through different software layers. The software runs on an edge-computing node in the form of a smartphone device with an Android operation system. Figure 3 illustrates the different

Personal Analytics and Coaching App
Analysis of the data from the different wearable sensors and the provision of feedback to the user is done through different software layers. The software runs on an edge-computing node in the form of a smartphone device with an Android operation system. Figure 3 illustrates the different layers of the system. This approach facilitates independence between layers, allowing for the update or substitution of any of them without hindering the system's performance.

Data Acquisition Layer
Data are acquired from the different wearable sensors, which make use of the Bluetooth communication standard to connect to the smartphone device, emulating a body area network operation. The user can select from a list of sensing devices based on the needs of different ergonomics variables of the assessment. The options are inertial measurement units (IMUs), and electrocardiogram (ECG) and thoracic bioimpedance recording devices. The smartphone connects to the sensors, initially configuring them based on preset specifications, emphasizing the frequency control of data acquisition and communication, filtering implementation, and data formatting.
Sensors 2019, 19, x FOR PEER REVIEW 5 of 17 layers of the system. This approach facilitates independence between layers, allowing for the update or substitution of any of them without hindering the system's performance.

Data Acquisition Layer
Data are acquired from the different wearable sensors, which make use of the Bluetooth communication standard to connect to the smartphone device, emulating a body area network operation. The user can select from a list of sensing devices based on the needs of different ergonomics variables of the assessment. The options are inertial measurement units (IMUs), and electrocardiogram (ECG) and thoracic bioimpedance recording devices. The smartphone connects to the sensors, initially configuring them based on preset specifications, emphasizing the frequency control of data acquisition and communication, filtering implementation, and data formatting.
This layer also controls and applies calibration algorithms, which require a direct interaction with the configuration functions of the sensing devices' firmware, enabling treatment of the raw data from the sensors to calibrate the referential systems for inertial measurement units and other referential-type sensors.
This layer formats the acquired raw data to a standard format to be used by the subsequent layers. Synchronization of recordings from different sensors is done by adding timestamps to the data.

Data Fusion and Basic Analytics Layer
This layer provides the system with the capability to transform the raw information extracted from the sensors into added-value information that can be analyzed to perform real-time multimodal risk assessments.
Firstly, preprocessing of the standardized raw data is performed. Data from the sensors is transformed from their original units, i.e., quaternions from IMUs or voltage from electrocardiographic recording devices, into units or information that are interpretable by the risk evaluation algorithms, i.e., transforming quaternions into Euler angles or voltage from electrocardiographic measurements into heart rate frequency. This process also includes data fusion from different sensors to produce additional useful information for the assessment, i.e., relative angles and angular velocity between two IMUs located in the body area network.
Processing and sensor fusion results in dramatic reduction of data sent to the cloud data warehouse. As an example, data from IMUs includes 3-axis gyroscope, a 3-axis accelerometer, and a 3-axis magnetometer sampled at sampling rates around 20−100 Hz depends on application. However, processed data from sensor fusion might just include the limb angles at a rate of 1 Hz sent to the cloud data warehouse. In some working scenarios, such as production lines, it might be interesting to look at workload at specific working or break cycles. To cover this scenarios, an extra processing of data can be done by allowing categorization of data based on sensor data, e.g., location data showing a station or even manual time stamps. This layer also controls and applies calibration algorithms, which require a direct interaction with the configuration functions of the sensing devices' firmware, enabling treatment of the raw data from the sensors to calibrate the referential systems for inertial measurement units and other referential-type sensors.
This layer formats the acquired raw data to a standard format to be used by the subsequent layers. Synchronization of recordings from different sensors is done by adding timestamps to the data.

Data Fusion and Basic Analytics Layer
This layer provides the system with the capability to transform the raw information extracted from the sensors into added-value information that can be analyzed to perform real-time multimodal risk assessments.
Firstly, preprocessing of the standardized raw data is performed. Data from the sensors is transformed from their original units, i.e., quaternions from IMUs or voltage from electrocardiographic recording devices, into units or information that are interpretable by the risk evaluation algorithms, i.e., transforming quaternions into Euler angles or voltage from electrocardiographic measurements into heart rate frequency. This process also includes data fusion from different sensors to produce additional useful information for the assessment, i.e., relative angles and angular velocity between two IMUs located in the body area network.
Processing and sensor fusion results in dramatic reduction of data sent to the cloud data warehouse. As an example, data from IMUs includes 3-axis gyroscope, a 3-axis accelerometer, and a 3-axis magnetometer sampled at sampling rates around 20−100 Hz depends on application. However, processed data from sensor fusion might just include the limb angles at a rate of 1 Hz sent to the cloud data warehouse. In some working scenarios, such as production lines, it might be interesting to look at workload at specific working or break cycles. To cover this scenarios, an extra processing of data can be done by allowing categorization of data based on sensor data, e.g., location data showing a station or even manual time stamps.
Finally, action policies are applied to enable the production of risk assessments based on the requirements established by the users and existing risk assessment algorithms, such as Risk Assessment and Management tool for manual handling Proactively (RAMP) screening [26].

Feedback Layer
Given the possibility of estimating the risks, the real-time analysis of the measured parameters allows for the production of feedback in real time, based on the triggering of different events abiding to the different action policies chosen by the users. The feedback for this system prioritizes user-friendly notifications, descriptions, and instructions that are easily understood by different users.
Different types of feedback can be used to adapt to different scenarios. Visual feedback, such as the display of information through the graphical display of the smartphone, can provide different levels of information based on the user's profile and display different parameters continuously, e.g., heart rate and activity recognition. Visual feedback could be a detailed report of the session or simply color-coded icons representing the different levels of risk, as well as a description of what caused that problem, enabling the users to minimize it.
The system is not limited to visual feedback. In most common working scenarios, the workers might not be able to interact with the screen, so an audio feedback system is preferred. A series of predefined coaching messages are given to the worker if an activity has been recognized as exceeding a risk threshold. The audio feedback is given at time intervals defined by the user. Haptic feedback using the actuators integrated in the wearables has also been tested and showed promising preliminary results.

Interoperability Layer
This layer provides the body area network with the possibility of connecting to a remote server solution to send the information processed by the data analytics and fusion layer. By formatting the time-stamped processed data into a JavaScript Object Notation (JSON) message, it is possible to use the Hypertext Transfer Protocol (HTTP) Representational State Transfer (REST) service to upload the data to a cloud platform or to a local server, depending on the restrictions of the deployment environment. In this sense, this layer offer to users the possibility to specify the server that has implemented similar REST APIs, described in Tables 1-3. By default, the accumulated data of the previous five minutes is uploaded, but the user can change this uploading speed to as fast as every second, allowing for the use of the information of the body area network for remote monitoring in a close-to-real-time manner. At the end of a work-day, the total work exposure is saved on the server, and a statistical summary may be generated, with variables that may be compared the recommended action levels, and to the levels of other occupations [27,28]. Especially when a group of workers have been using the system at the same workplace, this is a very time efficient way of objectively obtaining precise work exposure, and risk analyses, at a work group level.

Data Warehousing and Business Logic
The server was developed following a RESTful software architecture approach. This means all resources or services offered by the system on the server side are offered through HTTP methods. The data is stored in an open source relational database, PostgreSQL version 9.6.8, with a management layer by TimeScaleDB (Timescale Inc, NYC, US) added for the treatment of time-series records.
The Node.js 10.13.0 programming language was used for implementation of the server. Due to its nature, Node.js is oriented to the development of web applications, facilitating the encapsulation of all functions and procedures of the server into small RESTful services. Through a RESTful API, these services are offered to the other components of the system as simple web resources, identified by a textual representation. Figure 4 shows an overview of the relationships between the server side solutions and the other elements through the RESTful API.
The internal design of the architecture is based on modules. Each module brings together the functions and resources related to a specific objective: identity and security management, log management, data management, communication with third-party applications, and management of action policies. Figure 5 shows an overview of the architecture and the interaction between modules. These interactions can be generated by the direct action of the user (solid arrow) or as a consequence of an internal process (dashed arrow). The following sections define each of the modules. The internal design of the architecture is based on modules. Each module brings together the functions and resources related to a specific objective: identity and security management, log management, data management, communication with third-party applications, and management of action policies. Figure 5 shows an overview of the architecture and the interaction between modules. These interactions can be generated by the direct action of the user (solid arrow) or as a consequence of an internal process (dashed arrow). The following sections define each of the modules.

Identity Management Module
The security management of the server is based on a simple access and identity management system. Secure communication is implemented through HTTPS channels between the clients and the server and the use of REDIS and PassportJS as a solution for the management of certificates, sessions, and cookies.
This module enables control of access to the resources offered by the server and management of the users. This module allows for the management of permissions to the resources to generate different user profiles. Thus, the system can discern and adapt the interactions according to whether it is an administrator user that is more focused on the management of the system, end users, whether they are information consumers (analysts and experts) or workers, and other profiles necessary for the correct deployment of the solution. The resources offered by this module are detailed in Table 1.  The internal design of the architecture is based on modules. Each module brings together the functions and resources related to a specific objective: identity and security management, log management, data management, communication with third-party applications, and management of action policies. Figure 5 shows an overview of the architecture and the interaction between modules. These interactions can be generated by the direct action of the user (solid arrow) or as a consequence of an internal process (dashed arrow). The following sections define each of the modules.

Identity Management Module
The security management of the server is based on a simple access and identity management system. Secure communication is implemented through HTTPS channels between the clients and the server and the use of REDIS and PassportJS as a solution for the management of certificates, sessions, and cookies.
This module enables control of access to the resources offered by the server and management of the users. This module allows for the management of permissions to the resources to generate different user profiles. Thus, the system can discern and adapt the interactions according to whether it is an administrator user that is more focused on the management of the system, end users, whether they are information consumers (analysts and experts) or workers, and other profiles necessary for the correct deployment of the solution. The resources offered by this module are detailed in Table 1.

Identity Management Module
The security management of the server is based on a simple access and identity management system. Secure communication is implemented through HTTPS channels between the clients and the server and the use of REDIS and PassportJS as a solution for the management of certificates, sessions, and cookies.
This module enables control of access to the resources offered by the server and management of the users. This module allows for the management of permissions to the resources to generate different user profiles. Thus, the system can discern and adapt the interactions according to whether it is an administrator user that is more focused on the management of the system, end users, whether they are information consumers (analysts and experts) or workers, and other profiles necessary for the correct deployment of the solution. The resources offered by this module are detailed in Table 1.

Log Manager
All actions in the system must be logged to ensure the integrity of users. Therefore, the Log Manager registers all activities carried out in the server to process. The recorded logs are stored following the Common Log Format [29]. Through collaboration with the Data Management module, this module allows for exporting logs to a CSV format file that can be analyzed by experts. This functionality is encapsulated in a service managed by the Data Management module (see Table 4).

Data Management Module
In general, the P-Ergonomics solution uses two types of data-those generated by wearable sensors, and those obtained from the evaluations of the user's state, e.g., questionnaires or expert comments. In addition, sensors might be placed on different body parts or different types of questionnaires and subjective assessments can be used. Therefore, the data management module offers the resources required to support different data structures. The data of the sensors correspond to the structure described in Table 2. The information collected from the questionnaires is managed following the data structure detailed in Table 3. The resources offered by the RESTful API of the system related to the information management module are defined in Table 4.

External Communication Module
The interactions between the system and external agents are managed through the external communication module. In the presented version, interaction with wearable solutions from Polar Electro, Kempele, Finland, through the Polar AccessLink is implemented to retrieve the relevant user information, e.g., sleep time, daily activity, consumed calories, and resting heart rate. This integration is done through an Open Authorization (OAuth) protocol by asking users to share their Polar information with this platform. The access token and user identifier in the third-party system, e.g., Polar, are kept for the future operations, e.g., obtaining data from AccessLink (https://www.polar.com/accesslinkapi/#authorization-endpoint). The resources associated with this module are detailed in Table 5. /external/polar/listOf/{performance} GET Access and process the user's daily activity data from the Polar AccessLink and store them in the system database.

Analysis and Action Policy Module
The server offers the possibility to manage action policies based on the data collected by the sensors and questionnaires. These actions are based on previously designed analysis libraries that are included in the system before execution. The analysis results of the user data are managed following the guidelines established in the action policies, i.e., store or send to the user or to the coach.
In addition to internal feedback and notifications, this module allows for sending messages to third party applications. In the current version, it interacts with Pocket mHealth (ATOS, S.A., Madrid, Spain) [30]. The management of notifications in this third-party application is beyond the scope of the article. The resources offered by this module are described in Table 6. The process followed by this module to manage the action policies defined in the system and the interactions involved are shown in Figure 6. /api/v1/notification/pmh GET Perform analysis related to the health at work policy associate. The policy is defined as a main function in a library.
The process followed by this module to manage the action policies defined in the system and the interactions involved are shown in Figure 6.

System Validation
The proposed architecture and its implementation were validated through a realistic testing scenario. The objective of this validation was to evaluate the functionality, performance, and efficiency of the system for real deployment environments. Therefore, two types of tests were defined: a performance evaluation and a usability assessment.

Usability Assessment
The first stage of validation is to measure the usability of the system. A quantitative usability test, the System Usability Scale (SUS), was used [31]. The SUS questionnaire is a simple tool based on ten items to give a global view of subjective assessments of usability; that is, the effectiveness, the efficiency, and the user satisfaction related with the use of the system in order to perform a specific task. This test was carried out with N = 20 users in 4 groups of 5 users. As Nielsen noted in previous studies [32,33], this set of users is sufficient to tackle most usability problems and provides an overall view of the usability of the system. These users were selected from two different work types-office work and hospital work-to represent white-and pink-collar workers. The tests were carried out over 4-5 h for at least a working day in Spain and Sweden. In addition, all issues that occurred during the execution of the work activities were logged by an expert, such as interruption of the workflow due to system malfunctions. All participants were fully informed about the study and provided written consent. Ethical permission for the tests and data collection were obtained from the Regional Ethical Review Board in Stockholm (Dnr 2017/1586-31) and the local ethical board at Atos S.A.

System Validation
The proposed architecture and its implementation were validated through a realistic testing scenario. The objective of this validation was to evaluate the functionality, performance, and efficiency of the system for real deployment environments. Therefore, two types of tests were defined: a performance evaluation and a usability assessment.

Usability Assessment
The first stage of validation is to measure the usability of the system. A quantitative usability test, the System Usability Scale (SUS), was used [31]. The SUS questionnaire is a simple tool based on ten items to give a global view of subjective assessments of usability; that is, the effectiveness, the efficiency, and the user satisfaction related with the use of the system in order to perform a specific task. This test was carried out with N = 20 users in 4 groups of 5 users. As Nielsen noted in previous studies [32,33], this set of users is sufficient to tackle most usability problems and provides an overall view of the usability of the system. These users were selected from two different work types-office work and hospital work-to represent white-and pink-collar workers. The tests were carried out over 4-5 h for at least a working day in Spain and Sweden. In addition, all issues that occurred during the execution of the work activities were logged by an expert, such as interruption of the workflow due to system malfunctions. All participants were fully informed about the study and provided written consent. Ethical permission for the tests and data collection were obtained from the Regional Ethical Review Board in Stockholm (Dnr 2017/1586-31) and the local ethical board at Atos S.A.

Performance Evaluation
Another important aspect is to test the functional viability of the system using a performance test. The design of this test is based on the common behavior of a user while interacting with the system, i.e., skipping the connection setup of the wearable sensors. This behavior model is shown as a state diagram defined in Figure 7. Figure 7 shows the user interaction with the Edge App focuses on two main activities, the initialization or identification and the data collection. These two activities must be considered in the design of the performance test. Two processes comprise the information gathering, one related to the filling of questionnaires, and the other to the use of body sensors to measure movements and record physiological signals produced by the user. In both cases, the operation is similar: collect information, package it, and send it to the server to be stored and processed. However, the task of processing the data generated by the sensors is more complex due to the preprocessing performed in the Edge node. Therefore, the information gathering activity is modeled focusing only on the user's interaction with the questionnaires, as it considerably simplifies the implementation of the test.

Performance Evaluation
Another important aspect is to test the functional viability of the system using a performance test. The design of this test is based on the common behavior of a user while interacting with the system, i.e., skipping the connection setup of the wearable sensors. This behavior model is shown as a state diagram defined in Figure 7.  Figure 7 shows the user interaction with the Edge App focuses on two main activities, the initialization or identification and the data collection. These two activities must be considered in the design of the performance test. Two processes comprise the information gathering, one related to the filling of questionnaires, and the other to the use of body sensors to measure movements and record physiological signals produced by the user. In both cases, the operation is similar: collect information, package it, and send it to the server to be stored and processed. However, the task of processing the data generated by the sensors is more complex due to the preprocessing performed in the Edge node. Therefore, the information gathering activity is modeled focusing only on the user's interaction with the questionnaires, as it considerably simplifies the implementation of the test.
A Node.js library, Artillery.js, was used to implement the test using a human-readable data serialization file (YAML). This file defines two functional scenarios, where a virtual user should sign in and send the information related to a questionnaire to the server, with a similar workload to sending sensor data. Considering the probability of each scenario in real life, a weight was assigned to each, 1−4% to log in and log out, and 96−99% to upload information to the server.
As noted in previous research [34], a common scenario for a normal large company (logistics, manufacturing, etc.) is to have 120 workers for the same work line. However, a set of 50 simultaneous users could represent small-medium enterprises (SMEs) and 200 to 500 is more suitable for large corporations with more than 120 simultaneous users to be analyzed, if applicable. Thus, the test was performed by simulating 50, 120, 200, 300, and 500 users.
In terms of hardware, an Amazon Elastic Compute Cloud (Amazon EC2) (Amazon, Seattle, WA, USA) instance running the Ubuntu Server 16.04 was used to deploy the server, starting with the most restrictive set of resources, Amazon EC2 instance t2.nano. The test increased the resources, i.e., the Amazon EC2 instance type, when a use case demanded more CPU or memory. The client for data generation was simulated in an Amazon EC2 instance type t2.medium with Ubuntu Server 16.04, A Node.js library, Artillery.js, was used to implement the test using a human-readable data serialization file (YAML). This file defines two functional scenarios, where a virtual user should sign in and send the information related to a questionnaire to the server, with a similar workload to sending sensor data. Considering the probability of each scenario in real life, a weight was assigned to each, 1−4% to log in and log out, and 96−99% to upload information to the server.
As noted in previous research [34], a common scenario for a normal large company (logistics, manufacturing, etc.) is to have 120 workers for the same work line. However, a set of 50 simultaneous users could represent small-medium enterprises (SMEs) and 200 to 500 is more suitable for large corporations with more than 120 simultaneous users to be analyzed, if applicable. Thus, the test was performed by simulating 50, 120, 200, 300, and 500 users.
In terms of hardware, an Amazon Elastic Compute Cloud (Amazon EC2) (Amazon, Seattle, WA, USA) instance running the Ubuntu Server 16.04 was used to deploy the server, starting with the most restrictive set of resources, Amazon EC2 instance t2.nano. The test increased the resources, i.e., the Amazon EC2 instance type, when a use case demanded more CPU or memory. The client for data generation was simulated in an Amazon EC2 instance type t2.medium with Ubuntu Server 16.04, with similar hardware features to those offered by the real edge nodes used by the system. A description of the Amazon EC2 instances is presented in the Table A1.

Results and Discussion
The platform was tested in two different real work scenarios-one corresponding to white-collar workers at the ATOS offices in Madrid, Spain, and the other corresponding to pink-collar workers at the sterilization unit of the New Karolinska University Hospital in Stockholm, Sweden. Twenty users were enrolled and the system was tested for 4-5 h during a workday. These trials generated 2,601,016 measurements, an average of 130,050.8 per user. These measurements were used and analyzed to determine new activity detection algorithms, define new ergonomic suitability comparisons between jobs, or evaluate new occupational risks. Figure 8 shows the classification of the stored measurements and how each sensor contributed to the total. The IMU sensors (3 in each T-shirt) generated 73.53% of the measurements stored, with the angle between them being the most common type of measurement (48.61%). The least information came from third-party devices (Polar) at 8% of the total, because the raw data is stored in the Polar Access link server and only the essential information for the ergonomic analysis is retrieved, processed, and filtered according to the needs of the final application, i.e., calories, activity levels, and active steps.
workers at the ATOS offices in Madrid, Spain, and the other corresponding to pink-collar workers at the sterilization unit of the New Karolinska University Hospital in Stockholm, Sweden. Twenty users were enrolled and the system was tested for 4-5 h during a workday. These trials generated 2,601,016 measurements, an average of 130,050.8 per user. These measurements were used and analyzed to determine new activity detection algorithms, define new ergonomic suitability comparisons between jobs, or evaluate new occupational risks. Figure 8 shows the classification of the stored measurements and how each sensor contributed to the total. The IMU sensors (3 in each T-shirt) generated 73.53% of the measurements stored, with the angle between them being the most common type of measurement (48.61%). The least information came from third-party devices (Polar) at 8% of the total, because the raw data is stored in the Polar Access link server and only the essential information for the ergonomic analysis is retrieved, processed, and filtered according to the needs of the final application, i.e., calories, activity levels, and active steps. The analysis of the answers obtained from the usability tests (N = 20) yields an SUS score of 75,625 out of 100. According to most interpretations [35], this score indicates that the system has an acceptable usability level, i.e., a C grade. However, as shown in Figure 9, there is room for improvement. Figure 9. The SUS score of the system (dashed red line), with a visual explanation of adjective ratings, acceptability scores, and school grade scales in relation to the average SUS score [35].
This margin of improvement is visualized in the representation of the answers given to each question of the questionnaire outlined in Figure 10. The analysis of the answers obtained from the usability tests (N = 20) yields an SUS score of 75,625 out of 100. According to most interpretations [35], this score indicates that the system has an acceptable usability level, i.e., a C grade. However, as shown in Figure 9, there is room for improvement. measurements, an average of 130,050.8 per user. These measurements were used and analyzed to determine new activity detection algorithms, define new ergonomic suitability comparisons between jobs, or evaluate new occupational risks. Figure 8 shows the classification of the stored measurements and how each sensor contributed to the total. The IMU sensors (3 in each T-shirt) generated 73.53% of the measurements stored, with the angle between them being the most common type of measurement (48.61%). The least information came from third-party devices (Polar) at 8% of the total, because the raw data is stored in the Polar Access link server and only the essential information for the ergonomic analysis is retrieved, processed, and filtered according to the needs of the final application, i.e., calories, activity levels, and active steps. The analysis of the answers obtained from the usability tests (N = 20) yields an SUS score of 75,625 out of 100. According to most interpretations [35], this score indicates that the system has an acceptable usability level, i.e., a C grade. However, as shown in Figure 9, there is room for improvement. Figure 9. The SUS score of the system (dashed red line), with a visual explanation of adjective ratings, acceptability scores, and school grade scales in relation to the average SUS score [35].
This margin of improvement is visualized in the representation of the answers given to each question of the questionnaire outlined in Figure 10. This margin of improvement is visualized in the representation of the answers given to each question of the questionnaire outlined in Figure 10. Note that the even questions refer to positive aspects of the usability of the system and the odd questions refer to negative aspects. It has observed that the system must improve around questions 1, 5, and 8. Question 1 refers to the user's desire to use the system at all times. In this sense, the use of wearable elements and smart clothes appears to condition the final acceptance due to comfort aspects and doubts related to cleaning. Question 5 refers to the level of integration of the elements that comprise the system, that is, the functional coherence between the sensorized elements, such as Note that the even questions refer to positive aspects of the usability of the system and the odd questions refer to negative aspects. It has observed that the system must improve around questions Sensors 2019, 19, 1225 13 of 17 1, 5, and 8. Question 1 refers to the user's desire to use the system at all times. In this sense, the use of wearable elements and smart clothes appears to condition the final acceptance due to comfort aspects and doubts related to cleaning. Question 5 refers to the level of integration of the elements that comprise the system, that is, the functional coherence between the sensorized elements, such as the smart shirt, watch, and app. Question 8 refers to the comfort of the system, i.e., the wearable elements, which must be revised to increase the overall comfort of the system. The questions are detailed in the  Table A2.
The performance test results are shown in Table 7. Depending on the number of users, it is possible to select a more restrictive Amazon EC2 instance type. The cost of each option is estimated by the amount of CPU credits used by the instance in 24 h (see Table A1 for the amount of credits offered for each instance type). The minimum amount of CPU credits necessary for a workday were estimated for each test. It is worth mentioning that performance numbers reported in Table 7 are heavily dependent on software implementation and cannot be generalized.
The performance scenario is designed as a worst case scenario, with simulation of request to the server at every second. However, in our actual scenario, one-second interval warehousing and cloud analysis of data is not required. Each limb data, from IMUs, was 150 bytes, and hence size of each packet corresponds to Header Bytes + (number of seconds * (number of sensors * 150)). In our pilots, we have used 300 s for synchronizing with the data warehouse, while the performance simulations are done in one second. Perhaps it might be desired to change to a binary communication in future to increase the efficacy.  Figure 11 shows the difference between the minimum credits needed and those offered by each type of Amazon EC2 instance on dedicated Linux servers. Although the most affordable instances (t2.nano, t2.micro, and t2.small) offer adequate performance for few users, the final price can be altered due to the number of CPU credits used. In contrast, an instance of type t2.medium offers the best performance/credits-used ratio. With an annual advanced payment of $312, it is possible to handle up to 500 concurrent users with a CPU usage of 52%. best performance/credits-used ratio. With an annual advanced payment of $312, it is possible to handle up to 500 concurrent users with a CPU usage of 52%. Figure 11. Graphical representation of difference between Amazon EC2 CPU credits offered by upfront payment for reserved Linux instances (type t2).
Another requirement of the system specification is the possibility to deploy the system on a local server. This is suitable for enterprises with highly restrictive policies about storing data on the cloud. The analytical part of the system, although it is implemented following a cloud service, can be deployed on private local servers. To achieve optimal performance similar to that offered by an Figure 11. Graphical representation of difference between Amazon EC2 CPU credits offered by upfront payment for reserved Linux instances (type t2).
Another requirement of the system specification is the possibility to deploy the system on a local server. This is suitable for enterprises with highly restrictive policies about storing data on the cloud. The analytical part of the system, although it is implemented following a cloud service, can be deployed on private local servers. To achieve optimal performance similar to that offered by an Amazon EC2 t2.medium instance, the server specification is at least a dual-core processor and 4 GB of memory. Servers with such a specification are very affordable.
The development of the P-Ergonomics platform is in line with projects by our research group at the Royal Institute of Technology (KTH) and Karolinska Institutet, Sweden, and by our research partners. It is a part of the European Institute of Innovation and Technology (EIT) Health funded project [23], We@Work (http://weatwork.eu/). In a previous study [24], we demonstrated a wearable system integrating textrodes, motion sensors, and real-time data processing through a mobile application. Heart rate, respiration, and motion measurements obtained from a wearable system were fused to enhance the energy expenditure estimation [36,37]. Preliminary results of changing workers' behavior after giving feedback is also reported [38]. The aim is to develop a comprehensive solution to promote and support a healthy and safe working life. To the authors knowledge, this approach is novel and has not been reported elsewhere.

Conclusions and Future Work
The developed platform shows promising results in collecting data from the edge node (Android application). For its part, the functional analysis has been done with a specific platform (Amazon EC2) and different results could be achieved with other platforms, such as Google Cloud or Microsoft Azure. In addition, the performance and capacity could be expanded by software or operating system optimization, addition of hardware resources, or the detailed study of communication and data exchange between the node and the server, i.e., data compression algorithms. However, the results show that as a whole, the capacity and affordability of the implemented system meets the required specification.
Inclusion of protocols that make use of universal sensors is another possible expansion of the system that can increase its versatility. The usability tests show acceptable results, although the use of specific smart clothes seems to condition the final acceptance. This has caused the redesign of a new integration of the ECGZ2 device in the wearable garment by its integration into the t-shirt directly, avoiding the use of the vest. Thus, more detailed tests, including long-term usage of the new wearable systems, are planned for future work. A detailed test of the system for changing users' behavior by giving relevant feedback is ongoing. The use of gamification for engagement of workers is already planned and will be implemented. The use of pervasive and wearable technology in ergonomics could be a vital factor in enabling cost-effective ergonomic risk assessments and solutions in the near future.

Appendix B
The usability analysis has been carried out through the use of the System Usability Scale (SUS). For this, the tested and accepted questionnaire that provides this method has been used. Table A2 specifies the 10 questions that make up this questionnaire. Table A2. SUS questionnaire.

Q1
I think that I would like to use this system frequently. Q2 I found the system unnecessarily complex. Q3 I thought the system was easy to use. Q4 I think that I would need the support of a technical person to be able to use this system. Q5 I found the various functions in this system were well integrated. Q6 I thought there was too much inconsistency in this system. Q7 I would imagine that most people would learn to use this system very quickly. Q8 I found the system very cumbersome to use. Q9 I felt very confident using the system. Q10 I needed to learn a lot of things before I could get going with this system.