Unified platform for storing, retrieving, and analysing biomechanical applications data using graph database

Abstract

Sensors and smart equipment are frequently used in biomechanical systems and applications in sports and rehabilitation to measure various physical quantities. Various sensors, measuring different parameters, can produce a large amount of data at high speeds and volumes that must be stored for real-time or post-processing and analysis. In addition to sensor data, metadata is an important component and can vary between biomechanical applications. Currently however, each application typically has its own unique data flow and storage solution. In this research, we present a universal data model solution that can be applied to any sensor-based biomechanical application in sport and physical rehabilitation. Our proposed cloud platform architecture allows for the manipulation of sensor data and metadata using a combination of Big Data and conventional techniques. The main idea of this research is to develop a platform that allows a universal way for any biomechanical application to handle its data regardless of the type of data and metadata. This is achieved by creating a universal data model, and implementing this data model in a generalized architecture using a graph database. We demonstrate the benefits of this approach using examples from existing biomechanical systems and describe the development of the cloud platform architecture and the underlying data model. We also provide an example of the use of this platform in a sport shooting application. This approach is unique in that it allows data from different sources and applications to be stored and processed using the same procedures and techniques, facilitating data analysis and application development. We envision this system will expand to multiple different biomechanical applications in the future. We expect that in time, the ability to compare various data and store different biomechanical datasets will become necessity. With the advantages of modern recommender systems and utilization of artificial intelligence, huge amounts of relevant and well-prepared data with useful metadata are required thus having such system is an important advantage for future biomechanical systems development. With the increase of people’s awareness and usage of devices that increase well-being and quality of life, presented platform and similar systems will play a pivotal role in shaping the future lifestyle.

Introduction

In recent years, information and communication technology (ICT) has become a key factor in enhancing our well-being and quality of life (QoL) [1]. A healthy lifestyle is understood to be significant for a person’s quality of life and well-being. One of the most important factors is an adequate amount and quality of physical activity in the form of recreational, amateur or professional sports. A variety of devices and systems of different complexity are used to quantify and evaluate physical activity. They measure various activity parameters and provide numerous results, from daily step count to complex motion analysis during various sport activities. The interdisciplinary use of ICT can be observed in a number of research areas, but it is particularly noteworthy in the field of biomechanical systems and applications for human movement. Such systems and applications are used for the acquisition, monitoring, improving, and motor learning of human movement. They are being ever more extensively used not only in sports, but also in physical rehabilitation [2, 3].

There has been a significant increase in the use of wearable sensor devices and systems in sports and physical rehabilitation in recent years. However, biomechanical applications using these sensor devices and systems are often designed for a single specific task and do not allow for the comparison or sharing of data between different manufacturers and research teams [4,5,6]. In addition, commercial devices are usually tied to their own proprietary application solutions for specific movements and activities. It can also be difficult for the average user of commercial systems such as smartwatches or body trackers to access and understand useful data analysis and information.

To address these issues, we propose a cloud platform that provides a unified solution for the storage, processing, and comparison of data and results from various biomechanical systems and applications. We have previously presented this platform in different development phases [7, 8] and this paper summarizes and offer an update on the work presented at the conference [8]. In [7] we present a cloud platform design concept and explain the system requirements, and in [8] we explain some initial concepts for implementing graph database with respect to the proposed platform. The platform solves the problem of multiple independent systems by unifying them into one solution. It is hardware independent, allows data exchange between different devices, and supports various levels of signal processing and data analysis.

Our goal was to develop core components of a cloud-based platform that could address the issue of having multiple, standalone biomechanical applications [9]. At the moment, each of these applications has its own method for storing sensor signals and metadata, its own analysis process, and its own method of presenting results. However, despite the diversity of data structures and their processing, there are commonalities that can be exploited. For instance, similar sensors and sensor devices are used in various sports and physical rehabilitation therapies. We were motivated by the fact that we mastered most technical aspects of devices, communication, processing and analysis, and were able to create a tool that could improve our development of different applications.

The development of this platform is an ongoing process, and in this paper we present some new and existing contributions that have evolved from our previous work [7, 8]. The main contributions of this work are:

• the development of a generalized platform architecture for biomechanical applications (extended),

• the definition of a universal data model for biomechanical applications (new),

• the implementation of this data model in a graph database (new).

These unique approaches allow us to create a new cloud platform specifically tailored to the field of biomechanical systems. To the best of our knowledge, no other research group in this field has tried this approach before, and we have used technologies that are not common in this field.

We developed the proposed platform with the intention of:

• Provide a flexible cloud platform for biomechanical systems and applications that can be used by users with different skill levels.

• Provide a data interface for various applications, such as testing and measurement of athletes’ physical abilities, motion analysis, motor learning, physical rehabilitation therapies, and daily training support for coaches, real-time biofeedback applications, and more.

• Ensure adequate tools and processes are in place based on the needs and requirements of various biomechanical systems and applications.

• Standardize the data acquisition interface.

• Universal data storage solution.

• Allow for a set of standardized (but not exclusive) processing algorithms and analysis tools.

• Allow for a set of standardized (but non-exclusive) visualization elements that can be used with any sensor-based biomechanical application.

• Establish permission based collaboration based on data that is relevant to users and the task they must perform.

• The platform also enables the analysis of anonymized data for general studies.

The remainder of this paper is organized as follows: in Sect. 2, we define the problem in detail. In Sect. 3, we present existing solutions. In Sect. 4, we describe how our solution works. In Sect. 5, we provide a detailed explanation of our solution and its inner workings. Finally, in Sect. 6, we conclude with a summary of our findings.

Problem definition

Biomechanical systems and applications for human motion are a rapidly growing field of research. In recent years, advances in sensor and communication technology have enabled the development of a number of biomechanical applications in various sports and physical rehabilitation therapies. Accordingly, the amount of data collected with these applications is growing exponentially, and it is reasonable to expect a synergistic outcome in the form of significant results in sports and physical rehabilitation, all leading to a higher quality of life [1, 2, 10]. As a greater amount of data will allow new analytic tools such as artificial intelligence, to contribute meaningfully to the field of biomechanical feedback, incorrect movements of athletes and patients can be observed, detected, and corrected [3].

Our research group has developed several biomechanical feedback applications [2] for different sports and physical rehabilitation activities. We found that although each application was developed for a specific movement or activity, they share some common characteristics, use similar data structures, employ sensors of the same type, require similar signal processing and data analysis tools, etc. Consequently, we have used similar but not the same solutions for data acquisition, storage, processing and analysis. For example, we have used solutions such as simple relational databases and binary or text files to store our data and metadata. Since each application requires distinct metadata and has unique sensors arrangements and environmental parameters, it is virtually impossible to use only one solution for all the different biomechanical applications unless one uses a universal “backend” thet we propose in this paper. We have also found that there are important processing and communication requirements [11] for biomechanical applications and systems that we must keep in mind when developing universal solutions for data storage, manipulation, and analysis.

An important finding is that it is very difficult to compare results from different applications when each biomechanical application is a separate solution, even if developed by the same research group. Also, different applications and tools must be used to evaluate each biomechanical movement. We decided to merge the data from different biomechanical applications into a single platform that allows the acquisition, storage, processing, and presentation of signals, data, and results.

Biomechanical applications can generate a large amount of data about human locomotion, depending on the wearable sensors and devices used in specific applications and under specific conditions [11]. An important component of any biomechanical application is metadata about human subjects as well as application-specific variables. These data and metadata from biomechanical applications are relational and can have an extremely high data acquisition rate. For example, when using multiple sensors with high sampling frequencies. Therefore, the platform for biomechanical applications must support a relational data structure that enables fast data acquisition and storage. It must be easy to change and adapt as new types of biomechanical applications emerge. It must also be scalable as one or more of these applications become popular and used by the general public worldwide.

After all the above, a platform for biomechanical applications is or will soon be a Big Data problem. We can describe it with most of the multiple Vs (Volume, Variety, Velocity, etc.) and some other properties typical of Big Data problems (Relational, Scalability, etc.) [12, 13]. Currently, our datasets are moderate in volume, but we expect them to grow over time with new applications and users. Biomechanical data has a lot of variety, with multiple sensors generating different types of signals, data, and metadata, which also vary from application to application. Some biomechanical applications that require human motion to be sampled at high frequencies also generate data at high velocity. Our data is also reliable, as this is important for analysis, so it has good veracity, but this cannot be expected for all future biomechanical applications on the platform. New biomechanical applications may have different requirements and characteristics, so our platform must support variability. Data can be understood in a relational structure, where metadata and data are linked, and a non-relational structure. With this insight, we believe that our cloud platform solution should be developed with Big Data in mind, which also requires flexibility and scalability [13].

Existing solution(s)

There are many existing Big Data solutions that are utilized extensively by researchers and the industry [12]. This paper proposes a solution that uses big data technologies for data storage and manipulation. As the use of new wearable and connected devices increases, more data will be generated, leading to a greater demand for Big Data solutions. Research projects have produced specialized cloud platforms for specific sporting activities and rehabilitation purposes, which have been developed by other research groups [14,15,16,17,18,19,20]. These are mainly custom build specialized cloud solutions that are designed for a particular sporting activities and utilize traditional data storage and processing techniques. In one example, researchers in [14] created a cloud platform that includes a sensor device and phone application, which enables virtual cooperation between a patient and therapist by storing and displaying data on human motion and posture. The solution is implemented using a single server with a relational database. In [15], Rowlands et al. propose a solution that utilizes a single server for activity monitoring. The solution involves custom MATLAB processing for data received and stored on the server. They store metadata in both a relational database and XML data format. In [17], a cloud golf training platform is proposed that connects to multiple wearable sensors and provides insights for students learning golf. Hong-jiang et al. in [18] study the requirements for cloud applications in sport training and suggest the use of Big Data technologies, as described in [12], as the building blocks of future applications. The use of Internet of Things devices and cloud technologies is also discussed in [19], in which a cloud system is proposed that enables full cooperation between athletes and trainers in athletics. There are two main concerns with all existing solutions. First, they are specific to a particular physical activity. This means that they are really good as specialized solutions, but they lack the universality that could be beneficial in more complex applications are being proposed. Second, the existing solutions usually work with relational SQL databases and implement simple web or cloud technologies, because the authors were primarily concerned with solving their specific problem, which can be solved with less powerful hardware and technologies. On the other hand, we propose a Big Data solution in the cloud using various technologies, including NoSQL databases [12], of which graph databases store relationships between data using graph theory [21]. To date, no biomechanical application using graph databases have been found. The benefits of using graph database, which offer both the flexibility and scalability of NoSQL databases and the strong relational model of relational databases, are valuable in biomechanical applications where metadata and data are interconnected.

One of the key features of our solution is its versatility and including important requirements mentioned in Sect. 5. By using a single data structure, it can be applied to a wide range of applications, making it highly adaptable and suitable for use in a variety of scenarios. Additionally, our solution is designed to be highly scalable, allowing it to handle large amounts of data with ease, even as the volume of data grows over time. This makes it an ideal choice for users and applications dealing with large amounts of data that need to be processed and analyzed quickly and efficiently. Finally, our solution offers a unified API for communication between devices and users, enabling seamless integration and interoperability with other systems and platforms. Overall, these features make our solution a standout option for anyone looking to streamline their data management and analysis processes.

Proposed solution

Our solution is predominantly based on the specialization innovation method, as defined by classification [2, 22]. It also incorporates elements of the implantation and adaptation methods [22, 23]. The proposed solution can be considered specialization, as it was created using a specific top-down approach based on common knowledge and technology, resulting in a solution specific to our domain. The solution can also be described as implantation, as existing solutions were utilized in a new way to create an improved solution. This also means that the solution exhibits traits of adaptation, as multiple similar solutions were used to create a new solution that is well-suited to our specific needs.

Our platform and data model can be used in a variety of biomechanical applications. The goal of this platform is to provide flexibility and usability for a range of sports and rehabilitation applications. Although there are general similarities between these applications, different sensors are used in different sports and physical activities under different conditions, and data from these sensors is transmitted to various devices or cloud services. This platform is unique in its ability to serve different applications using a unified data structure, which is beneficial for (later) data analysis and sharing. The data flow and user interactions of biomechanical applications can be described using the process diagram in Fig. 1. Each biomechanical application in this platform represents a specific experiment, in which a measurement is taken with one or more test subjects and one or more devices. During the measurement, activity is often repeated several times, and this repeating process is a main part of the overall process that connects all other parts to the signals and data generated during the measurement of activity. In the experiment, specific variables must be identified and recorded as part of the measurement.

Fig. 1

An example of a typical platform use. Experiment is a specific biomechanical application that uses its own devices and sensors. Measurement is an instance of an experiment with a specific subject. Each repetition of the activity generates signals and data coming from sensors and measuring devices

In this paper, we propose a cloud platform that implements the described process in the data model and builds upon the knowledge of various biomechanical applications [9] and computing and communication requirements [11]. We have developed a unique cloud solution that allows for the storage, manipulation, and analysis of data from different biomechanical applications and makes them interchangeable. The platform is designed to serve a variety of devices and users. Figure 2 shows the general architecture of the proposed platform, which is divided into four main parts:

• Ingest API enables communication with multiple devices and protocols and provides data acquisition. It connects sensor devices, systems and applications and allows them to send data to the proposed platform.

• Control API that enables different kind of operators to manage the platform.

• A server/cloud based infrastructure hosting processing nodes, graph database and file system for storing data and metadata.

• Presentation API that offers different users information they require in a manner useful to them.

All components of the platform, which are interconnected, provide a universal experience for devices, developers, and users, regardless of the chosen applications and types of sensor devices. The platform acts as a universal storage and management tool for data.

Ingest API

The platform is independent of the sensor device type, but it relies on the proper format in which devices send data to the platform via the Ingest API. It consists of a set of procedures allow multiple devices to share measurement data from their sensors with the platform. The Ingest API enables both real-time and offline data streaming, where the data can be time series or single triggered events. All sensor data that is sampled can be considered as time series. Since we are dealing with biomechanical data, appropriate sampling rates and stability of sampling are the most important components of any time series. Events can also be triggered by different sensors. They usually represent a change of state, and their most important information is therefore the time of the change of state. This means that if multiple trigger sensors are used, they must be synchronized to provide meaningful information. This API also allows importing data from offline devices and transfering data from other platforms and data stores. Data about the data, i.e., metadata, can also be sent through this API. The devices can be simple microprocessors with connected sensors, smart devices, smart sports equipment and various computer-based applications. They generate or collect the data and forward it to the platform via a predefined protocol.

Control API and storage

The platform is supervised via a dedicated Control API. This API manages how data and metadata are used and stored by the platform. The Control API is used by the operator of the platform, i.e., administrators, experts, professional trainers, therapists, developers, or other knowledgeable users. Typicaly task of the operator include defining user policies, manipulating (meta)data, controlling data flow during measurement, programming new applications, and updating existing modules. The (meta)data is stored in a database and in the file system, with metadata stored in a graph database and data from sensors and devices being stored in a special format in the file system. Application developers can develop their own additions to their specific applications as add-on modules.

Presentation API

Users of the platform can access and interact with the data through the Presentation API. Typical users of this API are athletes, coaches, therapists, field experts, analytics, and other visualization or analysis tools or systems. Athletes, coaches or therapists can access their specific view and view the data according to their authorization. This enables the review of measured activity and associated metadata to investigate and improve physical skill or increase wellbeing. Views and user interfaces can be application-specific, but universal signal display and comparison arealso possible. Application-specific processing using custom algorithms and export specifications can be provided as part of the Presentation API as an add-on. This API also allows connection to other visualization or analysis tools that cannot be easily integrated into the platform, and provide these tools with the data they need.

Fig. 2

General architecture of the proposed platform. Data is received via the ingest API. The operation and structure of the platform is manipulated by the Control API. Stored data is presented to different clients through the Presentation API. Each API group is populated by different entities and supports a number of processes

Elaboration

The primary function of a cloud application is the back-end storage of data and metadata. To accomplish this, the development process was divided into several stages: planning and requirements, design, development, and data model implementation. In order to make the proposed platform feasible, certain requirements and guidelines were established and followed during the development phase. Additionally, a database schema was designed and incorporated into the application architecture during the development phase. Metadata is generated from interactions or relationships between components in the process or workflow (as depicted in Fig. 1), and actual data is created by a combination of sensors and the performed activity.

System requirements and design guidelines

To ensure the reliability of the platform, certain requirements must be followed. These requirements primarily pertain to the metadata and data received from sensors, as well as the needs of users and biomechanical applications. There are specific requirements that should be followed for each biomechanical system and application [11, 24], as well as general requirements for constructing online IoT or sensor platforms [15, 25, 26], that should be taken into account during the design of the platform.

Biomechanical signals and sensors

In biomechanical systems and applications in sport and physical rehabilitation, various sensor and measurement devices are utilized to measure the activity, i.e. the movements of the body or its parts. These sensors include (wearable) kinematic sensors, strain gauges, force plates, optical capture systems, video cameras, load cells, electromyography sensors (EMG), and others. For example, a typical wearable kinematic sensor used in biomechanical applications includes an accelerometer, a gyroscope, and sometimes a magnetometer. Each sensor measures a particular physical quantity and has its own units, dynamic range, and other properties. In the case of a streaming sensor device, producing sensor signals, an important parameter is also the sampling frequency.

Online platform requirements

Processing

The software of an online platform must be able to prioritize requests based on processing needs, with real-time or near-real-time device inputs being given higher priority than metadata inputs. The platform should be scalable and portable to allow for quick changes to the systems or hardware it runs on, and the ability to run multiple instances can improve performance.

Multiple devices and users

The platform should be able to serve multiple clients (devices and users) independently, optimizing its performance to handle simultaneous requests from various clients with appropriate responses or actions. In the case of real time or near-real time systems, response time is also an important property. Devices must use predefined protocols of communication in the known format with proper authorization and identifiers, and different restrictions may apply to clients operating in different modes (such as specific data from certain devices or users with specific privileges).

Data storage

Data storage is a crucial aspect of any online platform. Applications that operate on the platform have data storage needs that the platform must consider. The speed at which data can be read and written is a critical factor in determining the overall speed of the platform. The database system should be chosen based on the requirements and complexity of the data for the platform.

Data access and APIs

The platform must allow other applications to access and manipulate its data through an application programming interface (API), allowing for remote data manipulation and the use of multiple management applications on a single platform. APIs are necessary for both input and output, and incoming data must be checked to ensure it does not disrupt the existing data structure. Output APIs may serve multiple applications or be specific to a single application.

User interaction

The user interface of the platform should be designed to be easy to use and allow users to manipulate the system with minimal difficulty. Only users with the appropriate authorization should be able to view or manipulate certain data.

Security

The platform must be secure against attacks on any open communication channels and able to detect and defend against unwanted or malicious requests. If the application involves personal data, it must adhere to relevant standards and laws concerning such data. Users should be able to view their data and may choose to share it with other specified users, in our case as coaches or therapists. Before using data that may contain personal information, it must be anonymized, and users must have the option to request the permanent deletion or anonymization of their private data.

Custom implementation requirements

The proposed system must implement the above requirements, but implementation will be done in stages. In the first phase, the system will not support real-time operation. It must be able to handle and distinguish between two types of sensor data: streaming and asynchronous. Streaming data primarily consists of sensor signals, while asynchronous data includes various triggers, events, results, and other important metadata. In the second stage, it is expected that the platform will allow the execution of application-specific scripts and software, and certain data analysis tools for rapid signal analysis and statistics will be integral to its future use.

Entity-relationship data model

An entity-relationship (ER) data model is hardware and software independent. We designed an ER diagram, allowing us to test the abstract data model. The ER diagram can serve as the starting point for any database and was specifically used to implement a graph database model. The data model, depicted in the form of an ER diagram in Fig. 3, can be used to represent the majority of biomechanical applications. Data and metadata from biomechanical applications have clear relationships. Therefore, we designed an ER data model, which allows for a better understanding of system components, users, and environmental variables as well as the logical relationships between all of them.

The Unified Modeling Language (UML) was employed to describe the entities and their relationships. The entities in this model are physical objects (such as devices and subjects) or abstract concepts (such as experiments and measurements) and are depicted in boxes with their names and parameters. These entities are connected based on the nature of their relationship, which is represented by specific names and describes the interaction and hierarchy between the entities. The top-level and general entities in this model are Sensor Type, Activity, User, and Subject, which are generally related to more complex entities. The second-order entities are Sensor, Device, Experiment, and Subject Properties, which are more specific and connected to both upstream and downstream entities. The most specific entities in this model are Measurements and Data, which are derived from the measurements. Repetitions of measurements are represented as connected measurements.

Fig. 3

Entity-relationship diagram of database schema. Entities are in square fields with relationships named between them. Entities include proposed required parameters necessary for the platform

Graph database

The entity-relationship diagram from Fig. 3 itself illustrates the hierarchy between entities, which are referred to as nodes in graph theory, and relationships, which are referred to as edges in graph theory. Even though diagram can be used to create a database structure in any type of database, it is most commonly used to create relational databases. However, it is also possible to implement this model in a graph database, as we have done in our case. We chose to use a graph database because our data is interconnected and hierarchical in nature, what is supported by graph databases. In addition, graph databases allow much more flexibility of entity connection and parameters than relational database. To implement this data model in a graph database, we designated all entities as possible node types and all relationships as connected edges, as shown in Fig. 4. The direction of the connection reflects the logical and, in many cases, linguistic connection between the node names and the verbs used as edge names. Each node or edge can contain multiple parameters or variables that are associated with its type.

Fig. 4

Graph database schema. Entities are now considered nodes, and relationships directed edges. Edge direction is assigned according to the meaning

Architecture implementation

A database schema was used to create the platform architecture shown in Fig. 2 in the graph database implementation. The platform consists of four components that were implemented on a Node.js server using the standard model controller design. The focus was on ensuring the expandability and flexibility of the data storage and database. The platform has multiple interfaces for interacting with data: an Ingest API for applications and devices providing data and metadata, Control API and Presentation API for users to manage and view the data. Sensor data is streamed as evenly sampled signals or sent as asynchronous events and may or may not be synchronized among different devices participating in an experiment. The data is sent to the platform in text format, with the structure and order of the data packets customized for the existing sensors and applications. If the requirements change, it may be necessary to modify the functionality of the Ingest API.

In addition to online measurements, the platform also supports offline measurements in which sensor devices store sampled signals directly on a storage medium. These measurements can be imported into the platform at a later time. For measurements that are part of existing prototype devices and biomechanical applications and have some form of database as a storage medium, there is a tool available to transfer data and metadata from the existing database into the structure required by the platform.

The Control API allows its users to monitor and manage the data on the platform, for example adding new measurements. This API can be accessed through an online management application or via API calls from another application. The Control API also enables users to enter metadata and parameters for new measurements and users. Depending on the application, users can edit or enter information about the participant, specify the device type and sensors, and connect them to the experiment. The main responsibility of the operator is to start and stop the measurement, i.e. collect data from the sensor devices. Users may also have the ability to import or export data to and from the platform, depending on the application requirements and their assigned permissions.

The transfer of sensor data from sensor devices to the platform is automated and easy for the operator to manage. The operator, who may be a coach, athlete, therapist, or patient, is responsible for managing metadata that cannot be obtained from the sensor devices, such as data about the person and experiment circumstances/parameters. The operator defines the experiment and its parameters, specifies the devices and sensors, and for each measurement, defines the user and enters any necessary morphological and personal parameters and experimental variables. As data is received through the Ingest API for each measurement, it is stored on the platform. The operator is responsible for starting and ending the recording of signals and data. Multiple operators, users, and devices can use the platform simultaneously, although there may be a hardware limitation on the number of sensor devices available for a particular experiment.

Data and metadata are stored in two separate data stores. Metadata is stored in the form of a directed graph in the Neo4j database [21], as shown in Fig. 4, while data from the sensors is stored in JavaScript Object Notation (JSON) format. These two repositories are connected to each other through unique identifiers. The use of two data stores allows for faster queries and a simplified data structure, and also offers a different kind of interaction with data we use in current applications utilizing relational databases. The Neo4j database allows for a clearer structural design and easy scalability in the future. Also, graph databases are faster than relational databases for deep searches, which is useful for complex searches [27], something that will be important as the platform usage grows.

We developed a data structure that is universal, but also allows for specific operations for different experiments. The important components of this structure are: Platform User, Subject (participant), Activity, Experiment, Sensor, Device, Measurement, and Data. These components are interconnected as shown in the data model in Fig. 4. Each specific application is defined in the proposed platform as an experiment, which is associated with an activity. Each experiment requires the assignment of one or more devices and the sensors contained within those devices. Each repetition of an experiment with the same or a different user is considered a measurement.

Sampled data from sensors is stored in the file system as JSON files, which are given unique names consisting of a randomly generated sequence and the date and time of the measurement. We have concluded that storing time series data in the graph database, does not bring any benefits, on the contrary can have downsides when it comes to speed and responsiveness of the database. The name and file path of the file storing the time series data is recorded in the database (node Data) in a universal format that is structured and applicable to all types of devices, sensors, and in all experiments. Data from sensor devices or existing applications is reformatted to be compatible with the platform, whether it is sent in the form of packets or coming from existing files or databases.

An important aspect of the unified platform is the ability to export raw data for analysis in other tools. The platform in general allows for export in standard formats such as CSV (comma-separated value) or JSON (JavaScript object notation), regardless of the experiment or application. This offers experts, analysts and researchers an ability to access and analyze the data using familiar data processing tools. With an addition of custom modules, future development of the platform will include experiment specific exports and view in conjunction with integrated universal signal processing and data analysis tools. The structure of the platform allows for development of specific applications or experimental analysis scripts and view modules that coaches, athletes, or other users can use to display results, charts tables, reports, and other forms of textual information and visualizations necessary to understand movement during a particular activity. Such application-specific usage would require development of an additional module in the Presentation API.

The platform has different levels of access to data and metadata for different types of users. In the coach-athlete or therapist-patient relationship, it is appropriate for the coach or therapist to have access to the data of their clients, but not the data of other clients participating in the same experiment. However, domain experts conducting a study on the selected experiment should have access to all measurements, including anonymized data if necessary.

Sport shooting application Use Case

The proposed platform is suitable for use with various biomechanical systems and applications. As an example, we present the transfer of the existing sport shooting biomechanical application onto the proposed platform. As presented, the platform can be used with a sensor system for shooting evaluation, which utilizes specialized hardware as measurement devices, a computer application, and a dedicated database structure to store and process data [28]. The data model of a relational database implementation is shown in Fig. 5.

Fig. 5

Relational database structure of the shooting application with table names and parameters. Consisting of four tables from left to right: first defines the person shooting or subject, second one defines shooting or measurement, shot table defines repetition, and last one includes samples from sensors

The platform’s universal data structure allows for easy transfer of data from the current shooting application to the platform. To demonstrate the use of the proposed platform, we used data from a shooting application stored in a relational database. We had problems with this application, especially with data storage, because storing and retrieving sample data from and to the relational database took too much time for the application to be used efficiently. Since the advantages of the platform could be used in this application, we developed an import script to facilitate the transfer of data from the current relational database structure to the new graph database and platform structure. Visualization of the graph database can be complex, as shown in Fig. 6, so this visualization was done only as a demonstration for a limited data set. For actual work with the data, the graph database offers speed and search advantages that are not possible in relational databases [27]. Figure 6 shows measurements from three different subjects (red nodes), each with 25 shots (brown nodes, gray nodes are measurement files). This way of visualizing the graph database has no real use in the actual application, it is just a demonstration of how quickly, even with just small amount of data, the visualization becomes superfluous. For search, however, this graph visualization has significant advantages. To test the effectiveness of the platform with a specific application interface, we created a visualization tool to display the results of certain measurements, such as shooting (see Fig. 7). This user test interface includes several views for evaluating shooting, such as a target with results (red dots on the target), statistical measures (displaying the geometric center and standard deviation with blue arrows), and interactive comparisons and manipulations of sensor signals from the pistol (in the green rectangle) and measurement statistics (multiple shots) (in the orange rectangle). It also allows comparison between shooting episodes of different users. We show here only a simple visualization and statistics that can be created for any application. Since these types of visualization and analysis are application-specific, we show only one of them as an example. They should be considered as an application-specific add-on module for this platform.

Fig. 6

Graph database visualization that shows populated Neo4j database after the data transfer from a relational database. This is a visual representation of part of the proposed cloud platform database, this kind of visualization has no actual use in actual application but is a demonstration of how data is connected. All nodes are shown, but edges are not clearly visible

The platform can also be used in conjunction with an existing computer or desktop based application. In this case, the frontend of the current biomechanical application does not need to be modified, but the backend can be connected to the platform through API calls. The computer application no longer needs its own database and can use the platform as the backend. The existing shooting application includes some visualization and real-time processing features that have not yet been implemented on our cloud platform in this phase. It is possible to use both the application and the platform, with the platform serving as a means of storing, delivering data and results in a much more flexible way. This allows the application operators to manage the systems through the interface of the existing application they are already familiar with. However, they can use this platform as the underlying system for storing, accessing, processing and visualizing data. We expect that most likely future development will include changes of our existing applications [2] to conform with the proposed platform concept. With an existing desktop application still collecting data in real-time, providing visualization and means of collecting metadata, as this approach alleviates the need for hardware or software changes to the existing wearable devices. Desktop application only change is the connection to the platform, instead of using local storage solution such as local database or files. That change of course is not trivial in itself, but the benefits especially speed increase should be noticeable. When it comes to the development of new applications, it will also be simplified with this approach, as back-end task will already be implemented using platform’s APIs.

Fig. 7

Measurements visualization for shooting application, includes metadata about the athlete, individual shots and combined shooting episode results. Shot results are shown as red dots on the target, with their geometrical centre and standard deviation indicated by blue arrows. Shot (repetition) signals are shown in green rectangle and shooting (measurement) statistics in orange rectangle

Conclusion

Biomechanical applications using various sensors are a relatively new scientific field. The presented platform is intended to support such applications. First as a support for systematic data storage and later as a stand-alone platform for biomechanical applications. We anticipate that such a platform will change and accelerate the way new biomechanical applications are developed, including those with real-time feedback.

The proposed operating platform uses advanced technologies and enables hardware scalability. Currently, the amount of data is manageable, but it is foreseeable that this will become a Big Data issue with the widespread use of wearable systems and biomechanical application, which is why we have taken this into consideration during the development. Therefore, the proposed platform is relatively simple, yet universal and extensible.

We see the future of the proposed cloud platform in the implementation of multiple biomechanical applications. This will enable the unified storage of data and signals from all types of physical activity. Since large amounts of data are difficult to collect by a single research group, the proposed system will enable collaboration and combined work of multiple researchers. With this huge amount of information and knowledge, future developers of biomechanical applications can use statistical and artificial intelligence techniques to combine information from different applications and datasets to develop advanced recommendation systems and feedback applications. This makes our cloud-based platform design an invaluable tool for future advancements in the field of biomechanical feedback systems and applications and beyond.