Design of a Generic Wearable-Robot Monitoring System (GWRMS) for Patients with Lower Limb Paralysis

: The development of wearable robotic technology has accelerated recently due to active research in industrial technology. Wearable robots are used to help patients with lower-body palsy to walk. This paper reports a generic wearable-robot monitoring system (GWRMS) that supports resource monitoring and status prediction. The GWRMS o ﬀ ers universal support for operating systems that comply with the Portable Operating System Interface (POSIX) application programming interface (API), reducing limitations that arise due to the choice of operating system and processor. This system improves optimisation of a program operating in a robot-embedded system by detecting overhead in the software process of the wearable robot. In addition, it operates using TCP-socket-based monitoring on an on-demand basis only.


Introduction
Robots comprise a collection of embedded systems whose performance is sometimes limited by the requirement for high portability and mobility [1]. In addition, in some cases, embedded systems need to guarantee real-time performance. To address these requirements, previous studies have demonstrated methods such as kernel design to guarantee real-time performance [2,3]. Improvement of the performance of embedded systems can also be achieved through code analysis and optimisation.
The objectives of this study were to optimise the code for wearable robots and to predict their status by developing a generic wearable-robot monitoring system (GWRMS). The robot described in this paper assists with walking in patients with lower-body palsy. Since such patients can walk only by using exoskeleton robots, software optimisation is critically important. This can be achieved by monitoring the system resources of the wearable robot.
The GWRMS also works with any operating system that meets Portable Operating System Interface (POSIX) [4] standards. POSIX is a set of operating system application programming interface (API) standards established by the IEEE for the purpose of developing highly portable UNIX applications by organising common APIs for different UNIX operating systems. Most UNIX-like operating systems, with the exception of Windows, also follow POSIX standards.
In addition, the GWRMS can monitor the current status of the robot by analysing various data generated by the robot and storing the data on a cloud server for later analysis. The GWRMS also provides an interface through which developers of wearable robots can efficiently change component parameters.
The resource-monitoring function of the GWRMS allows monitoring of embedded systems and optimisation of each program operating in the robot. In addition, the resource-monitoring system uses the resources of embedded systems effectively, allowing on-demand operations through TCP-socket communication.
After predicting the status of the wearable robot, data generated by the robot for analysis (e.g., upper-body tilt, plantar pressure, motor angle, etc.) are stored on a cloud server. Thus, it is possible to predict the state of the wearable robot and improve its accuracy simultaneously.
As detailed adjustments to each motor and sensor are essential in the development of wearable robots, the GWRMS described in this paper supports both the display of system resources and the adjustment of component parameters. Adjusting component parameters can help wearable-robot developers to add or change functions.
The remainder of this paper is organised as follows: Section 2 introduces related research; Section 3 presents each key component in the implementation of the GWRMS from the perspective of robots, servers, and clients; and Section 4 describes the merits of the GWRMS and its limitations.

Related Work
Several previous studies have examined optimisation of the performance of embedded systems [5,6]. The most general and straightforward way to improve their limited performance is through code analysis and optimisation. Most robots are based on specific platforms, such as Linux-based robot-control middleware systems, including the ROS open-source project [7,8] and the i platform provided by IBM [9]. Energy-monitoring systems that operate only on certain processor architectures, such as ARM or MIPS, have also been reported [10,11].
With the exception of Windows, which is not widely used in robot-embedded systems [12], most operating systems follow POSIX standards, but there have been no reports on general resource-monitoring systems that can be used with multiple operating systems and processors. The GWRMS reported in this paper consists only of components that can be used in operating systems conforming to POSIX standards, unlike previous research based on specific platforms with a limited range of operating-system choices.
The GWRMS discussed in this paper supports status monitoring by supporting machine-learning through component parameters generated by the wearable robot, as well as resource monitoring supported by other systems. Table 1 compares the GWRMS with existing systems. The GWRMS is compatible with a wider range of operating systems than other approaches, and it uses basic TCP/IP communication to reduce network overhead as much as possible and minimise system overhead. Unlike Overseer or Robot Console, the GWRMS supports multiple platforms and is designed to use fewer resources. The GWRMS also has lower CPU and memory requirements than previous systems.
The GWRMS is not dependent on CPU architecture or operating system, so it can be used by many types of embedded system. In many cases, monitoring systems cannot be used because operating systems and underlying CPU architectures differ.
Compared to Overseer, the GWRMS is not dependent on specific frameworks, such as ROS and Nagios, and it has low resource usage due to its use of simple programs that run on performance-constrained hardware. In comparison to Drums, the GWRMS has better support for embedded systems because Drums is also dependent on the ROS framework, as is Overseer.
The GWRMS is also lighter because it uses TCP/IP, which is a core component of HTTP, rather than an HTTP server for communication. The overhead required for data visualisation is also smaller because the GWRMS does not implement cloud-server-based visualisation on embedded hardware, unlike previous systems.

Materials and Methods
The GWRMS is designed to operate on any operating system that follows POSIX standards and can support the following components (libraries): Lua, LuaSocket, and GNU Software.
The wearable robot described in this paper currently uses LabView, a Linux-based operating system; Linux follows POSIX standards, and LabView is therefore compatible with the GWRMS.
To aid in robot development, such as the addition of functions, the GWRMS can output and modify data (component parameters) generated by the various hardware components of the robot.
The GWRMS consists of three elements: a wearable robot, a server, and a cloud-server, as shown in Figure 1. Each component is described below.
Appl. Sci. 2020, 10, x FOR PEER REVIEW 3 of 12 The GWRMS is not dependent on CPU architecture or operating system, so it can be used by many types of embedded system. In many cases, monitoring systems cannot be used because operating systems and underlying CPU architectures differ.
Compared to Overseer, the GWRMS is not dependent on specific frameworks, such as ROS and Nagios, and it has low resource usage due to its use of simple programs that run on performanceconstrained hardware. In comparison to Drums, the GWRMS has better support for embedded systems because Drums is also dependent on the ROS framework, as is Overseer.
The GWRMS is also lighter because it uses TCP/IP, which is a core component of HTTP, rather than an HTTP server for communication. The overhead required for data visualisation is also smaller because the GWRMS does not implement cloud-server-based visualisation on embedded hardware, unlike previous systems.

Materials and Methods
The GWRMS is designed to operate on any operating system that follows POSIX standards and can support the following components (libraries): Lua, LuaSocket, and GNU Software.
The wearable robot described in this paper currently uses LabView, a Linux-based operating system; Linux follows POSIX standards, and LabView is therefore compatible with the GWRMS.
To aid in robot development, such as the addition of functions, the GWRMS can output and modify data (component parameters) generated by the various hardware components of the robot.
The GWRMS consists of three elements: a wearable robot, a server, and a cloud-server, as shown in Figure 1. Each component is described below.  Table 2 shows the configuration of the wearable robot. And Figure 2 shows data flow diagram showing the interactions between robot components and modules of the GWRMS.   Table 2 shows the configuration of the wearable robot. And Figure 2 shows data flow diagram showing the interactions between robot components and modules of the GWRMS.  The wearable robot uses LabView, a Linux-based operating system, to control component parameters such as motors, servos, and hydraulics, as well as a GWRMS that is composed of a resource-monitoring module, a component-monitoring module, a component-control module, a status-monitoring module, and a communication module. The roles of each component are as follows.

Wearable Robot
The robot in this paper is an exoskeleton-type robot that encloses the lower body. The GWRMS is composed of various modules and supports the POSIX operating system, so it can easily be used with various robot types. As most robot monitoring systems rely on specific platforms not included in the operating system, such as ROS, support for various types of embedded system hardware is insufficient. However, many robotic systems still use Linux, which is also POSIX-compliant, so the GWRMS can easily be ported to most operating systems.
The resource-monitoring module reports the CPU, memory, and processing resource usage of the wearable robot to the server. The component-monitoring module reports the state of the component parameters of the wearable robot, such as upper-body tilt, plantar pressure, and motor angle, to the server. The component-control module is responsible for application of individual control modifications sent from the server to the robot.
The status-monitoring module is responsible for collecting and reporting the data necessary for predicting the current status of the wearable robot to the server. The status-monitoring module collects data from the resource-monitoring module and the component-monitoring module, and then it organises and reports the data required to predict the status of the wearable robot to the communication module.
TCP/IP socket communication management between the server and the wearable robot is processed by the communication module. In addition, when monitoring data are requested from the server, the communication module activates other modules of the GWRMS and transmits the data from each module to the server via a TCP/IP socket connection.
Wearable robots use embedded hardware that has low processing power. Therefore, the operation of a GWRMS should not generate a level of overhead that would interfere with the normal operation of the wearable robot. Accordingly, in a GWRMS, the program used to operate the robot should be a daemon type program, and the system resources of the wearable robot should not be used when monitoring is not in progress.
Regardless of the hardware specifications of the device using the GWRMS, it enters an idle state while waiting for TCP/IP communication. Therefore, it generates little overhead. In addition, even when collecting data while not in an idle state, only necessary information is collected and transmitted. All operations associated with heavy CPU-resource requirements are performed on the server, so even in a non-idle state only a small overhead is generated. This is discussed in detail in Section 4. The wearable robot uses LabView, a Linux-based operating system, to control component parameters such as motors, servos, and hydraulics, as well as a GWRMS that is composed of a resource-monitoring module, a component-monitoring module, a component-control module, a status-monitoring module, and a communication module. The roles of each component are as follows.
The robot in this paper is an exoskeleton-type robot that encloses the lower body. The GWRMS is composed of various modules and supports the POSIX operating system, so it can easily be used with various robot types. As most robot monitoring systems rely on specific platforms not included in the operating system, such as ROS, support for various types of embedded system hardware is insufficient. However, many robotic systems still use Linux, which is also POSIX-compliant, so the GWRMS can easily be ported to most operating systems.
The resource-monitoring module reports the CPU, memory, and processing resource usage of the wearable robot to the server. The component-monitoring module reports the state of the component parameters of the wearable robot, such as upper-body tilt, plantar pressure, and motor angle, to the server. The component-control module is responsible for application of individual control modifications sent from the server to the robot.
The status-monitoring module is responsible for collecting and reporting the data necessary for predicting the current status of the wearable robot to the server. The status-monitoring module collects data from the resource-monitoring module and the component-monitoring module, and then it organises and reports the data required to predict the status of the wearable robot to the communication module.
TCP/IP socket communication management between the server and the wearable robot is processed by the communication module. In addition, when monitoring data are requested from the server, the communication module activates other modules of the GWRMS and transmits the data from each module to the server via a TCP/IP socket connection.
Wearable robots use embedded hardware that has low processing power. Therefore, the operation of a GWRMS should not generate a level of overhead that would interfere with the normal operation of the wearable robot. Accordingly, in a GWRMS, the program used to operate the robot should be a daemon type program, and the system resources of the wearable robot should not be used when monitoring is not in progress.
Regardless of the hardware specifications of the device using the GWRMS, it enters an idle state while waiting for TCP/IP communication. Therefore, it generates little overhead. In addition, even when collecting data while not in an idle state, only necessary information is collected and Appl. Sci. 2020, 10, 5566 5 of 12 transmitted. All operations associated with heavy CPU-resource requirements are performed on the server, so even in a non-idle state only a small overhead is generated. This is discussed in detail in Section 4.
To optimise the efficiency of the GWRMS, the communication module of the wearable robot's software uses a TCP socket to monitor data on demand instead of conducting ongoing monitoring. As shown in Table 3, this method improves the performance of wearable robots' embedded processors. When monitoring proceeds through TCP socket communication, the communication module collects data from each module, packs it as JSON string data, and sends it as a response to a TCP/IP request. The GWRMS utilises the functions of the following GNU software [13]: mpstat, ps, free.
The daemon software on the wearable robot of the GWRMS was implemented with Lua, and TCP socket communication was implemented with LuaSocket. Part of the pseudo code for the communication module is shown Algorithm 1.  send data length to client close client session for i = 1 to length of data do set client = accepted tcp session client timeout = 0 set partial = client data if partial not equal nil then send i th string of data to client close client endif endfor endif endwhile The pseudo code creates a TCP socket session and receives the session corresponding to the request when executing the request from the TCP socket. Then, after executing and collecting the command specified in the shell, a new session is created. The length of the message that can be sent in one session is limited, so the message length is first sent to the server. The entire message is then sent and the session ended. The server then receives the message until the message length specified at the creation of the session is satisfied.

Server
Among the components of the GWRMS, the processing modules of the server comprise resource-processing, component-processing, status-prediction, and communication modules, as shown in Table 4 and Figure 3. The pseudo code creates a TCP socket session and receives the session corresponding to the request when executing the request from the TCP socket. Then, after executing and collecting the command specified in the shell, a new session is created. The length of the message that can be sent in one session is limited, so the message length is first sent to the server. The entire message is then sent and the session ended. The server then receives the message until the message length specified at the creation of the session is satisfied.

Server
Among the components of the GWRMS, the processing modules of the server comprise resource-processing, component-processing, status-prediction, and communication modules, as shown in Table 4 and Figure 3.

Generic Wearable-Robot Monitoring System (GWRMS)
Resource-processing module Component-processing module Status-prediction module Communication module The resource-processing module unpacks the CPU, memory, and resource usage of each process received via the JSON string package through the communication module from each of the robot's processors, and it displays the data in the GUI client, as shown in Figure 4. The resource-processing module unpacks the CPU, memory, and resource usage of each process received via the JSON string package through the communication module from each of the robot's processors, and it displays the data in the GUI client, as shown in Figure 4. The component-processing module unpacks component data received from the communication module and displays the data in the GUI client, as shown in Figure 5. In addition, using the GUI buttons shown in Figure 5, component parameters can be modified, as shown in Figure 6 (e.g., adjustments to step length, cycle, toe height, and upper-body angle). This will assist in future development of the wearable robot, such as added functions.  The status-prediction module unpacks data received from the communication module, analyses the data in conjunction with big-data on the cloud server, and shows the robot's current status in the GUI client's status preview, as shown in Figure 4.
The communication module requests monitoring data from the wearable robot and relays the The component-processing module unpacks component data received from the communication module and displays the data in the GUI client, as shown in Figure 5. In addition, using the GUI buttons shown in Figure 5, component parameters can be modified, as shown in Figure 6 (e.g., adjustments to step length, cycle, toe height, and upper-body angle). This will assist in future development of the wearable robot, such as added functions. The component-processing module unpacks component data received from the communication module and displays the data in the GUI client, as shown in Figure 5. In addition, using the GUI buttons shown in Figure 5, component parameters can be modified, as shown in Figure 6 (e.g., adjustments to step length, cycle, toe height, and upper-body angle). This will assist in future development of the wearable robot, such as added functions.  The status-prediction module unpacks data received from the communication module, analyses the data in conjunction with big-data on the cloud server, and shows the robot's current status in the GUI client's status preview, as shown in Figure 4.
The communication module requests monitoring data from the wearable robot and relays the data from each module to the corresponding server module. In addition, it uploads processed data The component-processing module unpacks component data received from the communication module and displays the data in the GUI client, as shown in Figure 5. In addition, using the GUI buttons shown in Figure 5, component parameters can be modified, as shown in Figure 6 (e.g., adjustments to step length, cycle, toe height, and upper-body angle). This will assist in future development of the wearable robot, such as added functions.  The status-prediction module unpacks data received from the communication module, analyses the data in conjunction with big-data on the cloud server, and shows the robot's current status in the GUI client's status preview, as shown in Figure 4.
The communication module requests monitoring data from the wearable robot and relays the data from each module to the corresponding server module. In addition, it uploads processed data The status-prediction module unpacks data received from the communication module, analyses the data in conjunction with big-data on the cloud server, and shows the robot's current status in the GUI client's status preview, as shown in Figure 4.
The communication module requests monitoring data from the wearable robot and relays the data from each module to the corresponding server module. In addition, it uploads processed data to the cloud server and adds these to the big-data used for status analysis by the monitoring module. When component parameters are modified by the component-processing module, modified data are sent to the wearable robot's component-control module.
The GWRMS monitors the wearable robot's data and sends them to the server on request. The server processes the data and displays the resource status of the robot. If the user makes a request, the server sends the request to the wearable robot for execution. In addition, the server collects the data generated by the robot, sends the data to the cloud, analyses the data in light of big-data analysis, and displays the current status of the wearable robot based on the analysis.
If a machine-learning algorithm is executed based on the data generated by the wearable robot, the data used for analysis are uploaded back to the cloud server, and the learning data are reflected in the machine-learning algorithm. This feedback learning structure is shown in Figure 7.
Appl. Sci. 2020, 10, x FOR PEER REVIEW 8 of 12 to the cloud server and adds these to the big-data used for status analysis by the monitoring module. When component parameters are modified by the component-processing module, modified data are sent to the wearable robot's component-control module. The GWRMS monitors the wearable robot's data and sends them to the server on request. The server processes the data and displays the resource status of the robot. If the user makes a request, the server sends the request to the wearable robot for execution. In addition, the server collects the data generated by the robot, sends the data to the cloud, analyses the data in light of big-data analysis, and displays the current status of the wearable robot based on the analysis.
If a machine-learning algorithm is executed based on the data generated by the wearable robot, the data used for analysis are uploaded back to the cloud server, and the learning data are reflected in the machine-learning algorithm. This feedback learning structure is shown in Figure 7. Among the modules of the GWRMS, the status-prediction module has the advantage that data processed for status prediction are incorporated in the big-data database of the cloud server through a feedback learning structure. The data analysis process is shown in Figure 8. The status-prediction module analyses the data generated by the robot's status-monitoring module based on the machine-learning model and displays the predicted status through the server's GUI client, as shown in Figure 4. The machine-learning algorithm of the GWRMS is run on the server, so there is no associated overhead in the robot system. As mentioned above, the robot only transmits and receives data to minimise overhead, and it collects and processes essential data after receiving it.
Each component of the GUI client includes a status preview (Figure 9) that shows the current status of the robot's cloud settings (Figure 9). Cloud server data can be manually uploaded and downloaded to keep the data up to date, and a resource monitor (Figure 10) shows the resource status of the wearable robot. Among the modules of the GWRMS, the status-prediction module has the advantage that data processed for status prediction are incorporated in the big-data database of the cloud server through a feedback learning structure. The data analysis process is shown in Figure 8.
Appl. Sci. 2020, 10, x FOR PEER REVIEW 8 of 12 to the cloud server and adds these to the big-data used for status analysis by the monitoring module. When component parameters are modified by the component-processing module, modified data are sent to the wearable robot's component-control module. The GWRMS monitors the wearable robot's data and sends them to the server on request. The server processes the data and displays the resource status of the robot. If the user makes a request, the server sends the request to the wearable robot for execution. In addition, the server collects the data generated by the robot, sends the data to the cloud, analyses the data in light of big-data analysis, and displays the current status of the wearable robot based on the analysis.
If a machine-learning algorithm is executed based on the data generated by the wearable robot, the data used for analysis are uploaded back to the cloud server, and the learning data are reflected in the machine-learning algorithm. This feedback learning structure is shown in Figure 7. Among the modules of the GWRMS, the status-prediction module has the advantage that data processed for status prediction are incorporated in the big-data database of the cloud server through a feedback learning structure. The data analysis process is shown in Figure 8. The status-prediction module analyses the data generated by the robot's status-monitoring module based on the machine-learning model and displays the predicted status through the server's GUI client, as shown in Figure 4. The machine-learning algorithm of the GWRMS is run on the server, so there is no associated overhead in the robot system. As mentioned above, the robot only transmits and receives data to minimise overhead, and it collects and processes essential data after receiving it.
Each component of the GUI client includes a status preview (Figure 9) that shows the current status of the robot's cloud settings (Figure 9). Cloud server data can be manually uploaded and downloaded to keep the data up to date, and a resource monitor (Figure 10) shows the resource status of the wearable robot. The status-prediction module analyses the data generated by the robot's status-monitoring module based on the machine-learning model and displays the predicted status through the server's GUI client, as shown in Figure 4. The machine-learning algorithm of the GWRMS is run on the server, so there is no associated overhead in the robot system. As mentioned above, the robot only transmits and receives data to minimise overhead, and it collects and processes essential data after receiving it.
Each component of the GUI client includes a status preview (Figure 9) that shows the current status of the robot's cloud settings (Figure 9). Cloud server data can be manually uploaded and downloaded to keep the data up to date, and a resource monitor ( Figure 10) shows the resource status of the wearable robot.
Appl. Sci. 2020, 10, x FOR PEER REVIEW 9 of 12 Figure 9. Status preview and cloud settings of the GUI client. The PID(Process ID) and name of each process can be checked via the resource monitor's perprocess information button, as can CPU and memory usage, as shown in Figure 11. In addition, each item of information can be sorted in ascending or descending order. Figure 11. Per-process information of the GUI client.

Cloud Server
The cloud server component of the GWRMS receives and stores data generated by the robot via the GWRMS server. Data generated by the robot are incorporated in the big-data used to predict the state of the robot. The GUI client displays the status data via the process shown in Figure 8 and the machine-learning algorithm on the server as shown in the bottom right of Figure 4. Figure 12 provides a schematic diagram of the cloud server.   The PID(Process ID) and name of each process can be checked via the resource monitor's perprocess information button, as can CPU and memory usage, as shown in Figure 11. In addition, each item of information can be sorted in ascending or descending order. Figure 11. Per-process information of the GUI client.

Cloud Server
The cloud server component of the GWRMS receives and stores data generated by the robot via the GWRMS server. Data generated by the robot are incorporated in the big-data used to predict the state of the robot. The GUI client displays the status data via the process shown in Figure 8 and the machine-learning algorithm on the server as shown in the bottom right of Figure 4. Figure 12 provides a schematic diagram of the cloud server.  The PID(Process ID) and name of each process can be checked via the resource monitor's per-process information button, as can CPU and memory usage, as shown in Figure 11. In addition, each item of information can be sorted in ascending or descending order.  The PID(Process ID) and name of each process can be checked via the resource monitor's perprocess information button, as can CPU and memory usage, as shown in Figure 11. In addition, each item of information can be sorted in ascending or descending order. Figure 11. Per-process information of the GUI client.

Cloud Server
The cloud server component of the GWRMS receives and stores data generated by the robot via the GWRMS server. Data generated by the robot are incorporated in the big-data used to predict the state of the robot. The GUI client displays the status data via the process shown in Figure 8 and the machine-learning algorithm on the server as shown in the bottom right of Figure 4. Figure 12 provides a schematic diagram of the cloud server.

Cloud Server
The cloud server component of the GWRMS receives and stores data generated by the robot via the GWRMS server. Data generated by the robot are incorporated in the big-data used to predict the state of the robot. The GUI client displays the status data via the process shown in Figure 8 and the machine-learning algorithm on the server as shown in the bottom right of Figure 4. Figure 12 provides a schematic diagram of the cloud server.

Cloud Server
The cloud server component of the GWRMS receives and stores data generated by the robot via the GWRMS server. Data generated by the robot are incorporated in the big-data used to predict the state of the robot. The GUI client displays the status data via the process shown in Figure 8 and the machine-learning algorithm on the server as shown in the bottom right of Figure 4. Figure 12 provides a schematic diagram of the cloud server. Figure 12. Schematic diagram of the cloud server [14]. Figure 12. Schematic diagram of the cloud server [14].
The cloud consists of the cloud API and the public cloud. The cloud API supports uploading to, downloading from, and browsing of the public cloud, and it communicates with the GWRMS server's communication module.

Experimental Results
This section covers overhead and network latency when running the resource monitoring system of the GWRMS on a relatively low-end embedded system, Raspberry PI 4. Table 5 shows the specifications of the robot client system, Raspberry Pi 4, and the server system.  Figure 13 shows the results for the case where local and remote network communication are performed 1000 times with regard to network delay, when the server requests data from the robot system with a wired connection.
Appl. Sci. 2020, 10, x FOR PEER REVIEW 10 of 12 The cloud consists of the cloud API and the public cloud. The cloud API supports uploading to, downloading from, and browsing of the public cloud, and it communicates with the GWRMS server's communication module.

Experimental Results
This section covers overhead and network latency when running the resource monitoring system of the GWRMS on a relatively low-end embedded system, Raspberry PI 4. Table 5 shows the specifications of the robot client system, Raspberry Pi 4, and the server system.  Figure 13 shows the results for the case where local and remote network communication are performed 1000 times with regard to network delay, when the server requests data from the robot system with a wired connection. As shown in Figure 13, after measuring the network communication delay between the server and the robot client 1000 times, general network delays (average of 31.984 and 35.099 ms in local and remote network communications, respectively) were observed regardless of the type of network [15]. Table 6 shows the results regarding GWRMS daemon overhead in the robot system. Average memory usage of the GWRMS daemon was 3398 KB, and average CPU usage was 0.7% per second when each module was operated according to the TCP/IP message request received from the server. Delay between server and robot client Local Network Connection Remote Network Connection Figure 13. Network delay between robot and server.
As shown in Figure 13, after measuring the network communication delay between the server and the robot client 1000 times, general network delays (average of 31.984 and 35.099 ms in local and remote network communications, respectively) were observed regardless of the type of network [15]. Table 6 shows the results regarding GWRMS daemon overhead in the robot system. Average memory usage of the GWRMS daemon was 3398 KB, and average CPU usage was 0.7% per second when each module was operated according to the TCP/IP message request received from the server. Even in systems such as Overseer that have a small amount of overhead, there is a CPU usage gap of more than 2% between idle and running states. Therefore, the GWRMS daemon, which has a CPU usage of 0.7% while running, has a very low overhead regardless of whether it is in an idle state or not. In addition, Overseer uses 30 MB of memory even when monitoring is not being performed. In contrast, the GWRMS uses an average of 3 MB of memory, which means that it has a lower system overhead even with regard to memory usage.

Conclusions
In this paper, to improve the performance available from the limited specifications of a wearable robot, code optimisation was performed using a GWRMS. Existing monitoring systems are platform-specific, and no universal monitoring systems are available. The GWRMS introduced in this study can be used with any operating system that conforms to POSIX standards, and it is not dependent on a specific process, architecture, or platform.
As mentioned in related work, other systems are dependent on specific platforms, and it takes time and effort to port to an operating system or CPU architecture that is not supported by the platform. In contrast, the GWRMS can easily be ported to operating systems that meet POSIX standards. In addition, as mentioned in the Experimental Results section, the GWRMS is lightweight compared to other systems.
The system described in this study also monitors the status of the wearable robot. Future work should lead to improvements that allow status monitoring to be used to anticipate dangerous situations by determining abnormal conditions, causing the robot to shut down and thus preventing injury to the user.
The GWRMS is highly portable and supports many systems, unlike previous systems. In addition, the GWRMS utilises the most well-optimised software even when compared to previous studies that cite software optimisation as an advantage. Considering these advantages, the GWRMS can contribute to the productivity of the robotics industry.