Abstract
This paper proposes a model-driven approach for developing high-level software interfaces that allow developers to interact with wearable devices easily. These components hide the heterogeneity of the devices interfaces and provide developers with a simple and homogeneous way to interoperate with these digital peripherals. The use of this approach also allows reducing risks and development efforts.
1. Introduction
In recent years, the progress in several domains, such as electronics, communications, and computing has led to the creation of portable high-tech devices that provide several services to people and systems. In particular, wearable devices (or
There is a large and still growing variety of wearables since each vendor tries to differentiate their products from other vendors, in terms of services provided and costs. Consequently, they include proprietary software interfaces for these products, which cause clients and users to become highly dependent on the wearables of such a vendor.
Unfortunately, this lack of standard and open software interfaces (i.e., APIs (Application Programming Interfaces)) to interact with these devices limits the development of systems that really improve the quality of the people's life. For instance, if a developer has to implement a wearable system to monitor patients with Alzheimer's, the solution could involve at least a GPS, a computing unit, and a network interface. The GPS would determine the location of the monitored person. The computing unit would process such information to determine if the patient is moving according to his/her behavioral patterns. When this unit detects important changes in the person activity, it may assume that the patient is getting lost, and therefore it uses the network interface to notify other people (e.g., caregivers, relatives, or medical personnel).
The development of such a monitoring system would require that the software engineer would have to deal with the low-level software interfaces of the involved devices (the GPS and the computing unit), which probably vary depending on the device and vendor. Moreover, the interfaces of each device, as well as the details about data stream formats and transmission protocols, are usually provided through verbose datasheets, for which careful study and some training are also required so as to understand them.
This situation not only limits devices integration and interoperability of the solutions but also jeopardizes the development efforts of these systems, since it requires understanding and managing every device interface as well as writing specific source code for each device and operating system involved in the solution. Therefore, only highly experienced developers are able to address these challenges. Moreover, these developments require an extra effort (in terms of time and cost) and push developers to face unconventional risks derived from dealing with low-level abstractions used in datasheets device specifications, thereby reducing the success rate of these projects.
This paper introduces a proposal to deal with the heterogeneity of software interfaces for wearable devices, by enabling the design of high-level software interfaces that ease the development of these systems. The proposal, called model-driven approach for wearable system development (MDWSD), reduces the complexity and effort of using wearables, regardless of their specific characteristics (e.g., purpose, API, and supported communication protocols).
MDWSD provides a user interface that allows vendors to create high-level interfaces for their devices. Software designers (or architects), who may want to provide simple and homogeneous abstractions about these devices' APIs, can do the same for reducing the effort and risks of wearable system developments. Thus, developers no longer have to deal with low-level complex interfaces for interacting with a wearable device.
The proposed approach considers the use of several components: (1) a metamodel that eases the definition of the device design features and its API; (2) a design tool to be used by architects to model the wearables; (3) a mechanism to generate the device model from the proposed metamodel; (4) a software component, called
The device models are represented in a custom dynamic language, named wearable markup language (WML), which allows designers to specify the elements and features that are mandatory to interact with the device. Because of this, each wearable has only one model, as an instance of the proposed metamodel. Furthermore, the design tool has been conceived to generate wearable device models easily, particularly for devices with sensing capabilities. The
The rest of the paper is organized as follows: Section 2 describes related work; Section 3 presents a brief background on device development and integration; Section 4 presents the proposed model-driven development approach; Section 5 describes a case study in which the proposed approach was used; and Section 6 summarizes the conclusions and outlines the future work.
2. Related Work
Wearable computing has become an emerging and promising field because of the recent advantages in mobile computing and wireless communication technology. Several proposals based on the use of wearables are framed into the concept of wireless body area network (WBAN), where wearables from several natures support activities in various domains, such as healthcare or entertainment [6–8].
Most of these proposals have been designed to monitor people activities or health conditions. Provided that these solutions are focused on addressing a particular problem using specific devices, the seamless integration of several wearables in software applications is usually not addressed. Instead, the developers must create custom source code from scratch to interact with the wearables used in these projects.
Some other projects have considered the wearables integration an important challenge to address, and therefore they have proposed design solutions and infrastructures (e.g., middleware) to facilitate the software development process. For instance, in [9] the authors present an approach to improve the integration of Bluetooth based devices—in existing systems. In [10, 11] the researchers describe a middleware for supporting e-health environments, and in [12] a revision of several middleware is presented exposing their features, strengths, and weakness.
Most of middleware proposed to improve the integration of wearable devices is linked to particular elements; for example, specific communication protocols should be used [10] or it can be applied to a certain domain [11, 13]. Although they have shown to be useful, they provide a nonautomatic integration of devices and a limited support for device heterogeneity. This makes that developers have to write extra code to perform the devices integration process.
There are also proposals that intend to address the heterogeneity and lack of standardization for interacting with wearables, using a model-driven approach. For instance, in [14, 15] the authors propose an approach to enhance the data acquisition of wearables. Going a step further, the projects presented in [16, 17] explore the devices integration process, the lack of standardization, and the heterogeneity of wearable computing contexts. Based on that situation, the researchers propose model-driven approaches in order to address these challenges.
Recognizing the usefulness of the related proposals, they have limitations to address the challenge presented in this paper. Their main limitations are the following:
The integration of new wearables in already deployed systems, as well as the data management of wearables to provide a proper dissemination, is not fully covered. This is because in some cases the developers should create new source code from scratch. The use of these solutions requires understanding technical documentation, which is not usually written for regular developers.
In order to help address these limitations, this paper supports device development and integration, addressing problems such as the large variety of devices to integrate and the lack of the standardization about how to consume device services. The model-driven approach for wearable systems development (MDWSD) proposed in this paper intends to provide a solution for the integration and data management of wearable in an easy and quick way, providing a high-level interface to developers. Typically, the use of these APIs helps them reduce the development effort, risks, and complexity.
3. Integration of Wearable Devices
Wearable devices are small independent digital components that have been inserted in clothing, apparel, or personal portable objects and that have been designed or created for a specific purpose [18]. These devices are able to provide one or more functionalities, for example, to inform the user position, body temperature, and heart rate.
Some devices, like smartphones or wristwatches, may use these functionalities to provide complex services, like determining the health condition of a mobile user in real-time. Particularly, smartphones have become reference devices in wearable computing. Thanks to their computing power, usability, and wireless communication capabilities, they are gaining acceptance to coordinate other wearable devices of mobile users.
Wearable devices can use several, wired and wireless, communication interfaces, such as USB, Bluetooth, and WiFi, to exchange information with other components and devices. Regardless of the communication technology to be used and whether the information is sent by request (packets) or stream, wearable devices are designed to serialize the information and provide the results as an array of bytes with a predefined or undetermined length, structure, and content.
A customized device design entails that the structure of the serialized information provided by one device may be different from other devices that play the same role, since they have been designed by other vendors according to other criteria or requirements. Consequently, other aspects (such as the packet length, the provided information, or even the order of the information presentation) may be also different.
The left-hand side of Figure 1 depicts a wearable computing system with a smartphone as a central management device (i.e., the smartphone acts as a coordinator device), which monitors various other devices (a GPS, a smartwatch, and a breast-band heart rate monitor). The information gathered from these sensing devices (e.g., the user position, heart rate, and RR interval, time between two beats) starts with a header (H) to identify the starting point of the information packet, due to the different format and length of the packets they provide (right-hand side of Figure 1).
Smartphone as coordinator (a) and different packets of information (b).
The API (Application Programming Interface), designed by the architects from a particular vendor for interacting with one of the devices, provides a datasheet with all the device information (e.g., its technological features, size, and weight). The developers should use this datasheet to know how to interact with such a device, regardless of other concerns, like the communication protocols supported by the device. As a result, even two devices, designed by the same company, by the same engineers, and for the same purpose, could differ significantly in how to interact with them through their respective APIs.
This lack of standardization of the APIs jeopardizes the integration of wearables devices and leads software developers to several anomalous situations. For instance, if a vendor decides to release a new firmware to include additional communication capabilities in an already released device, the developers should write new source code and sometimes from scratch. Situations like this put in risk the development and operation of wearable computing solutions.
The dynamic nature of technology evolution should also be considered in the devices integration. For instance, we still have solutions using legacy wearable devices, which can only save information in an internal storage medium (e.g., MMC, SDCard, or Hard Drive). Although this reality represents a restriction in the design of wearable computing systems, it should be also considered for ensuring the devices integration.
4. The Proposed Development Approach
In order to address the challenge of using heterogeneous wearable devices in a system, we propose the model-driven approach depicted in Figure 2, which encompasses (1) a metamodel to define the different wearable device features, (2) a design tool to specify the features and the manner to interact with a device, (3) a device model generation process to obtain a device model from the metamodel, and (4) a coordinator component which is the software component that interprets the device models (metamodel instances) to interact with the corresponding devices. In the following sections, we describe each contribution in further detail as well as the integration process.
The proposed model-driven approach for wearable systems development.
4.1. Wearable Specification Metamodel
The metamodel proposed in this paper has been designed to be extendable and open, in order to enable the idea that new features and elements can be included in the future. This ensures that any wearable device can be modeled and eases the interaction with the devices from a software perspective. The metamodel is intended to support the design interface of any wearable device.
In the design process of the metamodel, some key concerns related to wearable devices have been identified. These concerns are represented or managed differently depending on the wearable device. The proposed metamodel encapsulates this heterogeneity and provides a single API to the developer, regardless of the device that he/she is manipulating. Thus, the metamodel helps ease the device integration. The key concerns considered in the metamodel are as follows:
The communication protocol is indicated in the metamodel, but how to handle it depends on the platform. For instance, protocols like WiFi, Bluetooth, and ZigBee are IEEE-defined communication standards; however, how these are used is still platform-dependent. While BluetoothSocket and BluetoothDevice are the API proposed in the Android Platform to work with Bluetooth Protocol, CoreBluetooth is the one proposed by iOS. They both work with the same protocol, but not in the same way from a developer's point of view. The wearable devices provide the information in a serialized array of bytes using two alternative ways: by request (synchronous packet) or by stream (asynchronous). The information provided by a specific wearable device is typically variable in format and length (buffer size, structure, and content). The dynamic information provided by a wearable device is specified in the same packet/stream. However, it can be in a predefined or undetermined position; that is, the position of the payload and other fields can vary within the buffer. The information provided by a wearable device starts with a customized value that we called The information provided by a wearable device has a cyclic redundancy check (CRC) or other similar mechanism to check that the packet is valid. The information provided by a wearable device is divided into groups of bytes. The length and position of these groups may be predefined or undetermined. The length of the buffer and the information position varies according to the service provided.
The metamodel is represented in a UML diagram in Figure 3.
Wearable device metamodel.
Depending on how the information provided through a communication protocol is managed, various features related to data structure/dissemination have been considered and included in the metamodel, in order to represent an abstraction of a wearable device. The considered features are as follows:
One of the design objectives of the metamodel was to make it customizable, so that it could meet present and future requirements of new wearables, as they are released. Because of this, it might be possible to create new customized models to cover forthcoming technologies and functions, by simply defining new concepts in the metamodel to support these new features and their implementation in the coordinator. The models generated from the metamodel (i.e., the instances) are represented in a custom markup language called wearable markup language (WML). These models are identified by a unique identifier called
Example of an instance of the metamodel.
4.2. Design Tool
Most wearables usually provide a datasheet or another kind of document where the developers can learn the device features and functionalities, in order to find out how the wearable works, that is, how to use the services of the device to get access to the sensed data. In some cases the datasheet is a huge file with all the device specifications on low-level implementation and data representation details, which hinders the use of the device for developers. Knowing how the device works is mandatory, but it usually requires expert knowledge.
In order to address this requirement, we have defined the role of
User interface of the design tool.
The designer, taking the datasheet and other information concerning the device operation (usually provided by the device's vendor), uses the design tool to define the features of any wearable at a high level of abstraction. The designer also establishes how to interact with the device through its API, generating thus a device model. Such a model is represented in WML.
In this manner, just one user or team with the role of designer is required to produce the model of a wearable. One developer with the WUI of the device, together with its API (defined by the designer), can use the device in an easy way just using the coordinator.
4.3. Device Model Generation Process
The metamodel, shown in Figure 3 and represented in an XML file, contains the different features of any (so far) wearable device, for example, the communication protocol, how the information is sent, and the packet-checking method. In order to define a device model (i.e., an instance of the metamodel), some of these features will be used to represent the device features. Therefore, it is mandatory to count on a procedure to get instances of the metamodel. In this approach it was implemented as a transformation process from the metamodel to the device model, as shown in Figure 6. The process to obtain the different device models is based on XSLT (Extensible Stylesheet Language Transformation) approach [19].
Device model generation procedure.
The designer, using the design tool, models the device. Then, the design tool automatically generates a style sheet document (XML file) based on the XSLT that represents the design of the device, that is, its communication protocol, type of buffer, and API. After that, a service generates a custom XML file (in WML) that represents the device model, by using an XSLT Processor, using the style sheet document and the metamodel file.
4.4. Coordinator
The metamodel proposed in this approach has been designed to generate device models to avoid facing the complexity of managing low-level detail information when coding for wearable-based systems. Although these models contain the necessary information to interact with the devices, it is also necessary that the software allows applications to use the wearable through this model.
The
Figure 7 shows a diagram that represents the coordinator design and its different elements. The coordinator is composed of four main components, each one has a specific purpose.
Architecture of the coordinator component.
Payload processing.
In order to handle the asynchronous interaction with devices, the coordinator uses a custom software component called
4.5. Using a Wearable Device
The approach proposed in this paper allows addressing the use of any device, regardless of its technical features and the lack of standardized access to the device information. This approach has been conceived to improve the use of new wearable devices in wearable computing contexts and facilitate and support part of the development tasks, thereby reducing the implementation effort (time and cost) and risk. In order to achieve this goal, the metamodel and the coordinator presented before are used in this process. Particularly, the use of a new wearable device supported by this approach consists of three stages, and it is represented in Figure 9.
Process to use a new device based on the MDWSD approach.
4.5.1. Design
The designer uses the design tool to come up with a device model API, compliant to the device features or datasheet. During this stage, the designer uses different device documentation to model the device interaction and defines a custom API to interact with the device in order to obtain the data provided/sensed by the device. The design tool uses the metamodel and device model generation process to produce a device model, which is stored in a wearable model repository (WR).
4.5.2. API Release
Once the design is finished, the design tool provides the API defined by the designer and also a unique identifier for the device model (i.e., the WUI). Thus, the developers are then able to access this API.
4.5.3. Interaction with the Device
With the API, the WUI, and using the coordinator, the developers are able to easily handle the device through the API and thus obtain the information in an easy-to-understand format, without the need to know about the device's internal workings or low-level details.
This approach entails the following advantages:
The developer can use any wearable device with no knowledge of communication protocols or the device workings. The possibility of defining a unique customized API for each device standardizes the access to the information, because all the users/developers utilize the device in the same way. If there is a bug in the device model, the designer can redefine it. If this redesign does not involve modifying the API, the software coordinator uses this new model in a transparent way for developers. Device models are platform-independent and they can be used by any coordinator, independently of the particular platform in which they are used (e.g., iOS, Android, and Windows). Each wearable device model is designed only once but used many times. The metamodel and coordinator are designed to be open and extendable. The metamodel is extendable to ensure that it adapts to new technologies or requirements. Changes in the metamodel entail changes in the new wearable model, and usually in the coordinator. For example, although a new communication protocol could be supported in the model, it should be also implemented in the coordinator.
This approach ensures interaction and use. Firstly, any developer with no expert knowledge can quickly use any device by simply using the API. Secondly, the coordinator should be able to detect new devices, access the repository to find its model, and incorporate it automatically.
5. Case Study
In order to illustrate the process of using wearable devices in a software application, Figure 10 shows a sequence diagram that represents the use of a sensor, from the design to the usage stage. The sample device is a Bluetooth multifunctional sensor (heart rate, temperature, accelerometer, etc.) with the specified API
Sequence diagram of the process to use a new multifunctional device.
The different steps to use a wearable, from scratch, are as follows:
The designer/expert reads about how the sensor works using the datasheet or other information provided by the vendor. The designer, knowing how the sensor works, uses the design tool to create the sensor model according to its features and defines a high-level API for such a device. Figure 11 represents a designer using the design tool to model the wearable from the datasheet where, for example, Once the designer concludes, the design tool generates the sensor model using the device model generation process. Algorithm 1 represents an excerpt of WML file with the sensor model considered in this case study. The design tool also releases the WUI ( The developer adds the coordinator (as a software component, e.g., a .jar file in Android) into the project. The developer uses the coordinator in conjunction with the WUI and the sensor API to interact with the sensor, as shown in Algorithm 2. Particularly, the developer can use the WUI to request the WML file through the coordinator. The coordinator, in turn, uses the WR component to obtain the sensor model and manages this model as an internal software element to handle the sensor through a pipe (class
<sensor> <id>JhDsX885Ip</id> <protocol>802.15.1</protocol> <name>Zephyr Bioharness 3</name> <api> <apisen> </apisen> </api> </sensor>
zCom. zCom. String WUI= String MAC= zPipe pipe=new zPipe(){ Object hr=msg.getData().get( object temp=msg.getData().get( Object resp=msg.getData().get( Object peak=msg.getData().get( }; zCom.
Device model design process.
In the application side, once the wearable device has been detected, connected, and synchronized, the coordinator starts interacting with the sensor by means of the components and processes the information according to the payload processing component.
When the coordinator has a correct and understandable value, according to the check error criteria specified in the sensor model, it launches an event in the corresponding pipe with the sensor information in a human-understandable format (e.g.,
6. Conclusions and Future Work
Wearable devices are constantly being launched in many different domains, such as healthcare, entertainment, wellness, and sport training. The architecture, operation modes, data streams, and representation formats of these devices are designed in a different way by vendors' engineers. This happens because of the absence of standards and reference models in the field.
This situation results in heterogeneous possibilities of interacting with these devices. Considering that designers are responsible for defining the manner in which sensor information is accessed through a custom and well-defined API, the heterogeneity and lack of API standardization hamper the use and integration of these devices. Therefore, developers must write source code mostly from scratch and deal with low-level details about the wearable technical features and interfaces, increasing the development effort and risk.
In order to help address these challenges, this proposal presents a model-driven approach that abstracts the developers from these challenges, by providing them device models and abstract APIs through which they can interact with the wearable devices in a simple way.
The proposed approach, named model-driven wearable systems development (MDWSD), comprises five main components: a
The metamodel allows developers to define the specification of a wearable device, regardless of its vendor-specific features. It also permits the specification of a custom API to access sensor information. This metamodel has been designed to be extendable in order to cover the requirements and features of future-released devices.
The design tool supports the definition of wearable models, which represent their features and how to interact with them. The device model generation process is used by the design toolto produce instances of the metamodel (i.e., each sensor model). The coordinator is the software component that handles sensor models in order to facilitate the integration of new devices and allow the use of these sensors in a seamless and transparent manner. Finally, the model-driven wearable integration process is the component that allows the MDWSD approach components to be coordinated through a single process.
This paper also presents a case study to illustrate the development of a software application that gets several functionalities from a commercial wearable device, by using the MDWSD approach. As a future work, we plan to make this proposal deployable as an open software solution, so that it can be used by any developer community.
Footnotes
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.
Acknowledgments
This work has been partially funded by the Facultad de Educación, Economía y Tecnología de Ceuta under the “Contrato-Programa” of research for the period 2013–2015. This work has also been supported by Fondecyt (Chile), Grant no. 1150252. The authors would also like to acknowledge input from COST Action AAPELE (IC1303).