Development of a Body Weight Support System Employing Model-Based System Engineering Methodology

Abstract

Partial body weight support systems have proven to be a vital tool in performing physical therapy for patients with lower limb disabilities to improve gait. Developing this type of equipment requires rigorous design process that obtains a robust system, allowing physiotherapy exercises to be performed safely and efficiently. With this in mind, a “Model-Based Systems Engineering” design process using SysML improves communication between different areas, thereby increasing the synergy of interdisciplinary workgroups and positively impacting the development process of cyber-physical systems. The proposed development process presents a work sequence that defines a clear path in the design process, allowing traceability in the development phase. This also ensures the observability of elements related to a part that has suffered a failure. This methodology reduces the integration complexity between subsystems that compose the partial body weight support system because is possible to have a hierarchical and functional system vision at each design stage. The standard allowed requirements to be established graphically, making it possible to observe their system dependencies and who satisfied them. Consequently, the Partial Weight Support System was implemented through with a clear design route obtained by the MBSE methodology.

1. Introduction

According to the World Health Organization (WHO), most people with disabilities experience mobility problems [1]. In particular, the disability of lower limbs affects their mobility; this is due to causes such as strokes, spinal cord diseases, paralysis, and polytrauma, among others [2]. These causes and the lack of physical activity in that body part induce muscular weakness and a progressive reduction of natural gait in patients. In critical situations, the patient cannot bear their weight. Consequently, there is a loss of self-sufficiency in daily life activities. Frequently, these disabling conditions cause some adverse psychological behaviors such as depression and anxiety, contributing to a loss of life quality [2,3,4]. Considering these situations, Body Weight Support Systems (BWS) are alternatives to help lower limb disability patients support a percentage of their weight, improving the gait rehabilitation protocols. Many types of research show that using BWS in physical rehabilitation protocols reduces the therapy duration and increases safety (among other benefits) [5,6,7,8,9,10,11,12,13,14]. In addition, there is an increasing interest in using BWS in other fields like sports [15,16,17,18,19,20,21]. Thus, exploring the research on developing BWS systems is relevant to improving physical rehabilitation in health and sports.

Table 1. BWS Literature Review Classification.

Type of Development	Conceptual Solution	Analytic Verification	Analytic Verification- Experimental	Mechanic and Control Systems
Theoretical [21,22,23,24,25,26,27,28,29,30,31,32,33,34,35]	X	X
Theoretical and practical [4,5,6,8,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58]	X	X	X	X

categorizes the information according to the type of development, description scopes, type of verification, and technological solution. This compilation shows limited information related to design methods, and authors focused on issues at specific stages of the design process. Therefore, this paper presents a contribution to literature about the development of BWS, highlighting their design methodology.

Over the years, the complexity of BWS has increased, tending to better performance [29,39,52,59]. It is essential to have design methodologies and BWS system implementations developed by an interdisciplinary group. Primarily, a rehabilitation system requires the cooperative work of several fields, such as physiotherapy, various engineering branches, and industrial design. This diversity in the development of rehabilitation devices implies clear communication. To solve this issue, the model-based systems engineering methodology (MBSE) uses the SysML (Systems Modeling Language) standard, which provides simple exchange of ideas among several knowledge fields. MBSE is a graphical tool that abstracts and integrates design parts, including stages and physical, digital, and cyber-physical components. INCOSE [60] proposes the use of the MBSE approach to developing a BWS.

MBSE is a flexible methodology in both software and hardware. So,

Table 2. SysML literature review classification.

Field	Research
Aerospatiale	[61,62,63,64,65]
Software architecture	[66,67]
Industrial	[68,69,70,71,72,73,74,75,76,77,78,79,80,81]
Control	[82]
General	[83,84,85,86]
Models	[87]
Education	[88]
Automotive	[68,89,90,91]
Software & Hardware	[18,22,92,93]

presents some fields of application. The health field has increased its interest in MBSE, which reinforces the motivation behind this research.

2. Materials and Methods

A Body Weight Support System allows patients with lower limb disabilities to reduce a percentage of their weight while performing physical therapy exercises. Additionally, the BWS needs to integrate closely with other equipment, such as treadmills or elliptical machines, to enhance the rehabilitation system and physical therapy exercises.

General requirements support the BWS prototype design according to the user’s needs. Figure 1A shows those requirements in a SysML Requirements Diagram (req). The main requirement is “to Support the lower limb disability patient’s weight partially and actively”. Other requirements include population type, workspace, and methods to support weight. These requirements initiate the development process and facilitate traceability. Upon prototype completion, they help estimate compliance with the objectives and results.

According to Figure 1, requirements are essential for conceptualizing the system and serve as a precursor to obtaining the use case diagram (route 1 in Figure 1). This diagram establishes the interactions between the BWS and everyone involved in the process. Figure 1C presents the general use cases according to the requirement of active weight support, considering the device users and their interactions with the BWS.

This diagram helps identify parameters for the prototype’s development, such as protocols for supporting the patient during physiotherapy exercises, parameters the therapist must set for the exercises, and system operation parameters. Use Case Diagrams are crucial for system development as they indicate which users interact with the system and help recognize the possible consequences of their actions. With the requirements and use cases, the next step is to follow and enter the information into development route 2—Figure 1. The BWS conceptual design begins with this action, setting up the main configuration.

According to the requirements, the BWS needs the assistance of a treadmill to perform the therapy exercises and actively support the weight. Additionally, the data collected from the rehabilitation process can be saved and sent to other devices, allowing the therapist to analyze each patient’s clinical history offline and from the comfort of a desk.

Figure 1B presents the system layout, highlighting the controller, which manages information between devices and users within the BWS system and facilitates signal transmission for weight unloading. According to the Use Cases Diagram (uc) in Figure 1C, there are three fundamental system users: patient, therapist, and support engineer. The support engineer configures the equipment and manages its maintenance, the therapist sets up the weight support and the rehabilitation exercise parameters, and the patient interacts directly with the BWS and the treadmill. The data transfer system between the BWS, treadmill, and the therapy management system includes the controller, the HMI, and the physio PC. An engineering PC interacts with all the system elements to manage the setup variables.

After the BWS configuration, development route 3—Figure 1 begins, and the information management packages or folders are created, allowing better organization of the subsystems. Figure 1D shows the SysML Package Diagram (pkg) and its blocks: the mechanical system, power system, and control system. These blocks perform the main objective of the BWS, which is to support the patient according to gait rehabilitation therapy requirements.

Another critical aspect of development is the system architecture, which identifies the subsystems and their interactions. The system architecture follows the conceptual design, proposing possible prototype forms and their components. Following development route 3—Figure 1E shows the general BWS architecture from a conceptual design [94], using a Block Definition Diagram (bdd). The system is divided into four subsystems: (1) Mechanical System, (2) Power System, (3) Control System, and (4) HMI. The mechanical system has two parts: (a) The mechanism, which transfers the weight unloading force from the actuator to the patient, and (b) the chassis, which supports all subsystems. The power system provides the necessary energy for the system’s performance. The control system has the command and control for active weight support and data feedback. Lastly, the HMI allows the physiotherapist to initiate the weight support process. The diagram also shows that the actuator resource is used for the mechanical, power, and control systems to achieve their tasks, and the control system uses the HMI.

With all the general definitions in place, the subsystems will be detailed to reach all the implementation specifications of the BWS. Following the methodology shown in Figure 1, the subsequent sections present each subsystem.

3. Mechanical System

The mechanical system has two subsystems, the weight unload mechanism and the chassis, which support all BWS components, as shown in Figure 1E. The following paragraphs explain each subsystem.

3.1. Mechanism

The mechanism subsystem transmits the movement and force from the actuator to the patient. This subsystem is the most relevant part of this project because most of the BWS’s performance depends on it. Figure 2 shows the mechanism design process starting from the “Mechanical System” block presented in Figure 1E.

As mentioned, following development routes like those presented in Figure 1 to develop the prototype’s subsystems ensures that each design actor understands the development process and maintains traceability of information. Thus, similarly to the general system, defining specific requirements for each subsystem is crucial. (These requirements are refined from the general ones and tailored to the mechanism subsystem.) Figure 2A shows the requirements for the mechanism, highlighting that the requirement “Active weight unload” is defined as “a system driven by an actuator that allows changes in force or torque”. for the requirements of the mechanism. This refinement extends to all the general requirements, giving traceability and hierarchy in the development process and who covers the specific requirements for the mechanism.

With the requirements and the conceptual design [94], the development route 2—Figure 2 is followed, which obtains the configuration scheme of the mechanism shown in Figure 2B. This mechanism operates using a rotational actuator with a gear motor connected to a drum around which the patient support rope winds; Figure 2C illustrates the configuration. A pulley system supports the rope, and a load cell measures its tension.

Development routes 2 and 3 in Figure 2 clarify the schematic of Figure 2B through the bdd diagram and the internal block diagram (ibd) presented in Figure 2D,E. The first one shows the mechanism architecture, highlighting system resources with black and white rhombuses. The patient, crucial for physical analysis during weight unloading according to [94], is external to the system. The actuator and the load cell are part of the control system, detailed in subsequent sections, influencing mechanism performance. The second diagram displays the flux of the physical signals between the mechanism components; the mechanism has a voltage source and induces a torque by the actuator, which is connected to a drum. The drum converts the torque into a force to unload the weight. Also, this diagram presents the physical quantities in the system. ibd makes it easier to see the signal changes and when and where they occur.

Once the mechanism architecture is finalized, the next step is to follow the development route 4—Figure 2F to show the mechanical system’s SysML Parametric Diagram (par). This diagram defines equations governing the system when the required torque block is the torque, ${\tau }_m$, given by the actuator, which supports the percentage of mass unload, $\delta m_p$, the torque is ${\tau }_m=r_d\left(\delta m_p\ddot{y}+\delta m_{p}g\right)$, $\ddot{y}$ is the patient’s center of mass acceleration, $g$ is the gravity acceleration, and $r_d$ the drum radius.

The weight support model considers the requirement of “active weight unloading”, for which the patient’s weight unloading force value must be fed back through a load cell that allows verification of the correct value of applied force by the actuator to unload the patient weight. The load cell senses all forces acting on the patient, including the inertial forces related to the movements of the patient, $\delta m_p\ddot{y}+\delta m_{p}g$. In this scenario, achieving constant mass discharge requires understanding all inherent variables in force measurement and compensating for this value is mandatory. To accurately sense model variables, an accelerometer measures the $\ddot{y}$, due to the patient’s natural gait. Thus, to obtain effective unloading force for the patient’s weight, the “ForceEquation” block represents the drum in the ibd, defined by the equation $T_r={\tau }_m/r_d$, where $T_r$ is the support rope tension. In general, Figure 2 specifies the mechanism models represented in the bdd illustrating the architecture, the ibd that exposes the physical interactions of the elements of the mechanism, and the pair diagram that shows the physical models that govern the system, taking into account that the subsystem building from the requirements. Therefore, it is important to note that diagrams are a relevant part of each design phase.

The MBSE ensured the definition of the mechanism from the RSM-M4 and RSM-M3 requirements in a simple mechanism that can connect a harness to the system to support the patient, as shown in Figure 2B. This approach covers RSM-M1 and RSM-M2 requirements, which specify the physical components, such as the actuator and the load cell. For instance, this approach covered the general requirements of RNC1, RNC2, and RNC4.

3.2. Chassis

In the same way as the mechanism development process, the chassis requirements derive from the general ones, as shown in Figure 3A. The requirement of “workspace for all subsystems in the main system” is the most critical part of the chassis design. This element must provide sufficient space for the mechanism, the power and control systems, the HMI, an adequate workspace for the patient, and support for a treadmill.

With these requirements and an established conceptual design, the development route 1—Figure 3 is followed. The architecture of the chassis was proposed as depicted in Figure 3B, encompassing the necessary components to address the RSM-A3 requirements from Figure 3A, complemented by subsystems from Figure 1D and Figure 2D.

Based on the established data and features in previous steps, development route 2—Figure 3C proceeded, resulting in a mobile and detachable arch structure due to the mobility condition request in the EC8 requirement. Continuing with design route 3—Figure 3D, the system is modeled with the Finite Element Method (FEM), providing a solution to the weight support requirement with the specified operating conditions. This FEM analysis was performed by modeling in Autodesk Inventor Professional 2023 Education Edition using solid-type elements with six degrees of freedom per node. A model with 111,719 elements was generated to ensure mesh independence. The analysis revealed a maximum stress of 15.12 MPa against the material’s 345 MPa yield strength, yielding a safety factor of 22.9, well above the required application threshold (greater than 5). The model also allowed the verification of the structural rigidity of the proposed solution; the modal analysis allowed us to identify that a person’s natural gait, 2 Hz, fulfills the Nyquist criterion; it does not excite the natural vibration modes of the proposed solution, and therefore, the system will not enter resonance. It is essential to clarify that the dimensional analysis generated with the use of the FEM model made it possible to unify the safety factors in static conditions, rigidity, and the visual sensation of robustness and safety for the user.

The procedure continues following route 4—Figure 3E, resulting in a the detailed design that includes an insulated enclosure for the mechanism, control and power systems, and mechanical supports for the load cell, rope, and patient safety equipment.

Based on the previous development, the solution proposed in Figure 3E satisfies the Chassis requirements defined in the req diagram in Figure 3A, obtaining a modular and portable chassis with a spacious workspace capable of integrating with a treadmill. Additionally, it incorporates visual aesthetics and calming colors to enhance therapy sessions. Chassis requirements are refined from the general requirements RNC3, RNC5, RNC7, and RNC8.

4. Power System

The power system provides the necessary energy to all BWS devices as per established requirements in Figure 4A. According to Colombian electrical regulations, the operating voltage should be 120 VAC, which implies avoiding the use of an external energy transformation system RSP1 requirement. This is complemented by protection from current peaks, phase loss, harmonics, and a variable speed driver for the actuator. Following the development route 1—Figure 4B, the architecture can be observed, encompassing key components like voltage inputs, converters, protections, and drivers. This architecture has shared resources, including the actuator used by the mechanism and therapist. The performance of the power system is significantly influenced by its interaction with the therapist.

The uc diagram in Route 2—Figure 4C shows the system interaction with users, obtained using the architecture and requirements. This diagram demonstrates that the therapist can activate the power system, turning it ON or OFF during routine and emergency operations.

Building upon the preceding diagrams, requirements, architecture, and use cases, development route 3—Figure 4D progresses towards defining the technical description of the electric circuit for the Power System, aligning with Colombian RETIE standards [95]. Understanding the interactions among system elements, the development route 4—Figure 4E combines the bdd and circuit to define the ibd. This diagram shows the required signals in every component and their sources and receptors. Among those signals, there are system inputs and outputs such as input voltage for all the equipment, manual signals given by the user (the therapist) to activate or deactivate the BWS, and the external signals to start and stop the gear motor, supplied by the control system and the limit switches.

In this stage of the process, the development route 5—Figure 4F leads to the Activity Diagram (act), outlining the operational sequence critical for the operations manual. The Power System works when the therapist turns on the main switch; then, the system checks the voltage levels. If they are suitable, the therapist can start the BWS and stop it when necessary.

5. Control System

The control system receives user actions and executes the instructions to unload the patient’s weight. Its development is based on the requirements outlined in Figure 5A, where RSC01 and RSC03 derive from the general requirement RNC2 “active weight unload”, along with other essential parameters such as setting up BWS parameters, requiring an HMI for therapists. Development route 1-Figure 5B establishes the control system architecture from the requirements; this figure shows the control system components, such as the embedded controller, the load cell shared with the mechanical system, patient protection elements, communication and signals interfaces, and the actuator driver.

The requirements and architecture diagrams support defining the user’s actions to build the uc diagram in the development route 2—Figure 5C. This diagram shows the operation mode for the control system, which is fundamental in the general system. Likewise, it is observed that the therapist can establish inputs and weight unload parameters, like lifting and releasing the patient, acting directly on the actuator driver’s performance. Those parameters include setting up the treadmill. Additionally, when the weight unloading begins, the data of the load cell sensor is required.

The control system layout is detailed in Figure 5D based on the control actions and the system architecture. This diagram displays control system elements, their interactions, and concentrates different control, sensing, and actuation signals within the Devices Interface (DI) component. This interface integrates signals from the several sensors and actuators with the processing system, which for the particular case is an embedded system with a 32-bit ARM processor at 84 MHz with 54 digital ports, 12 analog inputs, 2 analog outputs and I2C, CAN, and SPI communication ports [96].

The measurement component integrates three sensors connected to the DI: a load cell for obtaining patient weight (capable of measuring up to 200 kg, with an analog-to-I2C signal conditioner), an accelerometer with wireless RF communication to measure patient center of mass acceleration (Figure 2F), and a proximity sensor for system and user protection, signaling an emergency stop if the harness reaches critical heights, supplemented by a manual emergency stop.

The DI has an input/output port with the driver’s actuator where the signals from the actuator encoder are obtained, as well as other emergency signals. It transmits control signals for actuator operation, utilizing a 0 V–10 V signal for torque and speed control. USB communication with a device connected to the physiotherapist’s computer is essential for system operation, as indicated in Figure 5D.

Then, development route 4—Figure 5E presents the ibd with the component interactions and the signals used for the system performance in more detail. For example, the limit switch stops the system if an unwanted behavior; this is activated by an external mechanical action, which is the force exerted by the harness bracket. Another example are the patient’s weight and acceleration signals, measured by the load cell and the accelerometer. Specific signal interactions among DI modules are not depicted in Figure 5D.

The process advances with the design development route 5—Figure 5F, in which the control system’s act diagram is shown. This diagram is fundamental to implementing the command-and-control algorithms, ensuring synchronization of all BWS activities initiated by therapist actions.

The control system development process finishes with the controller design to fulfill the BWS’s requirements. The controller’s function is to maintain the patient’s weight within a stationary unload range, considering natural gait dynamics, as discussed in the mechanical system section.

The controller is a block of the Control System, as shown in Figure 5B. In this way, Figure 6A shows the controller’s requirements to perform the desired weight discharge. This req diagram shows that all the requirements are inherited from the general requirement of “active weight unload”. Another critical requirement is the system speed, as abrupt changes in the controller’s actions can increase tension in the rope, potentially harming the patient’s physical condition. Therefore, the BWS must perform low-speed actions accurately. Model simulation in a test case is necessary to verify the controller’s compliance with requirements.

Development route 1—Figure 6B obtains the controller par diagram derived from Figure 2F, identifying the required signal inputs to generate the controlled output signal modulating the actuator. Following this, route 3—Figure 6C establishes the typical control loop for the BWS, supported by the information in the pair diagram in Figure 2E which highlights the physical signals essential for unloading the patient’s weight. The tension of the rope results from the conversion of input torque to force by the drum, generated by the actuator torque, evident in the control loop. Additionally, the controller features a speed saturator to cover the low-speed requirement, and the loop plant is the patient. The control loop analysis is detailed in [94].

With the controller parameters, the development route 3—Figure 6D checks the fulfillment of the system requirements, including the ones of the control system and its controller.

6. Results

Developing the systems and subsystems of BWS, especially the control was greatly aided by the MBSE methodology This approach ensured that all requirements were met, providing strength and security at every stage of the BWS prototype design and implementation. Figure 7 shows the built system in which the design elements can be compared with those implemented through MBSE. For example, the chassis design shown in Figure 3B was based on the requirements presented in Figure 3A: the chassis should have enough room for the control, power, transmission subsystems, security belts, rope, and load cell.

In the other hand, Figure 8 compares the chassis bdd diagram shown in Figure 3B with the implemented BWS system chassis. This figure shows that the built system satisfies the development requirements with each subsystem following the same design procedure and traceable to the proposed model.

The MBSE, when implemented with SysML, proves to be a solid and comprehensible method for developing cyber-physical systems, as evidenced in BWS system development.

Besides the physical system development, the MBSE methodology is also repeatable for functional areas. Architectural and sequential diagrams can be developed for the BWS system and gait rehabilitation protocols for the devices and other system characteristics.

System elements are presented as block diagrams during the development process, and they help system analysis if any element’s structure or parameters change without modifying the whole model. The SysML models are reusable and can be applied to other development projects.

Using MBSE demonstrates a better design process in multidisciplinary fields. Various diagrams join different fields, such as mechanical, electrical, and control, and examine their interactions without losing the information thread.

7. Conclusions

A Body Weight Support System (BWS) was designed by using models and the Model Based System Engineering (MBSE) methodology, ensuring the traceability of the requirements. The established models allow for a more effective analysis of potential system failures by including interactions among all system elements. The MBSE methodology used in the BWS system development led to of solid results in cyber-physical systems, particularly in its representation using the SysML standard. MBSE enhances traceability in design processes, reduces the complexity of integration between the Body Weight Support subsystems, and provides a hierarchical and functional system view in each design stage. Equipment like the BWS requires the integration of a multidisciplinary work group both in its development and use, necessitating a methodology that facilitates this integration. To solve this, the SysML standard was employed, with the requirements established graphically, specifying their dependencies and influences to achieve a clear design route through graphic models understandable for the multidisciplinary team at each stage of the design. This approach enhances communication among all team members.

MBSE and a detailed inspection of the BWS system’s physical and functional components will improve the performance, security, and effectiveness of rehabilitation exercises.