Elmar Krainz

Johannes Feiner

Martin Fruhmann

Accelerated Development for Accessible Apps -Model Driven Development of Transportation Apps for Visually Impaired People

Keywords: Model driven Development, Mobile Apps, Accessibility

Implementing usable and accessible user interfaces is a challenge, especially for mobile applications. App developers have to include accessibility in an additional step during the implementation, very often they overlook this extra workload. There are concepts which combine Model Driven Development (MDD) for apps or semi-automatic support to create accessible software. But helpful tools to support accessibility features for apps during the implementation are hardly discussed in literature. The aim of this paper is a concept of model-based software development for accessible apps. Within the domain of transportation apps, we provide a model to create an app scaffold with the required elements and accessibility features included from the beginning.

Introduction

Mobile applications are one of today's fastest growing software areas 1 . Apps, with simple intuitive user interfaces, are easy to use. The UI is mostly based on graphical representation a touch input.

For visually impaired and blind people this interaction paradigm is a challenge. Accessible web or desktop applications are already widespread, but this know-how cannot always be adopted to mobile apps.

Including accessibility is a challenge for developers and therefore it is handled more like a feature or add-on than a prerequisite. This work shows an approach to use Model-Driven Development (MDD) to create accessible mobile apps.

Related Work

The topics Accessibility, Mobile Applications and Model-Driven Development are part of current research. This is also visualised in Figure 2 The main contribution of this work lays in the middle of the three circles, namely the intersection of all three domains. Following existing research is related to our approach:

The book Model driven Software Development (MDSD) from Voelter et al. covers the (semi-) automatic generation of software [START_REF] Völter | Model-driven software development: technology, engineering, management[END_REF], but mentions mobile devices only in one minor example and accessibility is not covered at all. In the fast growing area of mobile applications there is also a need for this agile and effective methods to create software. There are different approaches. Barrnet et al [START_REF] Barnett | Bootstrapping mobile app development[END_REF] describes a tool to generate data-driven apps based on a Domain Specific Language (DSL, compare [START_REF] Fowler | Domain-specific languages[END_REF]), with MD 2 form Heitkoetter et al [START_REF] Heitkötter | Cross-platform model-driven development of mobile applications with md 2[END_REF] even crossplatform apps are created from a model. The latter tool focuses on business apps where common source code is compiled into native iOS and Android apps, sadly neglecting accessibility topics.

MDD also helps to include accessibility in the development process. The Johar framework from Andrews and Hussain [START_REF] Andrews | Johar: A framework for developing accessible applications[END_REF] uses an interface interpreter to create accessible applications for a range of users with different abilities. González-García et al [START_REF] González-García | A modelbased graphical editor to design accessible media players[END_REF][START_REF] González-García | A model-based tool to develop an accessible media player[END_REF] use a model-based graphical editor tool to design an accessible web based media player. The UsiXML presented by Vanderdonckt [START_REF] Vanderdonckt | Usixml: a user interface description language for specifying multimodal user interfaces[END_REF] promotes the integration and use of a User Interface Description Language (UIDL).

For accessibility combined with mobile app development, there are several publication which discuss smartphone-based assistive technologies for the blind. For example, Narasimhan et. al. [START_REF] Narasimhan | Smartphone-based assistive technologies for the blind[END_REF] presented in 2009 the mobile phone tool Trinetra to assist visually impaired people during grocery shopping. Guidelines to develop for visually impaired and blind people can be found in [START_REF] Park | Toward accessible mobile application design: Developing mobile application accessibility guidelines for people with visual impairment[END_REF]. Harder [START_REF] Harder | Möglichkeiten der mobilität blinder menschen[END_REF] discussed the possibilities for general mobility already in 1999, but for several modern approaches of implementation and design of touch-based smartphone interfaces see [START_REF] Krajnc | User centered interaction design for mobile applications focused on visually impaired and blind people[END_REF][START_REF] Krajnc | A touch sensitive user interface approach on smartphones for visually impaired and blind persons[END_REF][START_REF] Barnett | Bootstrapping mobile app development[END_REF][START_REF] Mattheiss | Route descriptions in advance and turn-by-turn instructions-usability evaluation of a navigational system for visually impaired and blind people in public transport[END_REF]. These contributions focus on accessible way-finding apps as well as new ways of touchscreen usage for blind people.

A Concept for Model-Driven-Development for Accessible Apps

This work shows a concept to generate transportation apps for visually impaired and blind people. These people have special needs when it comes to live an independent life. Traveling and moving on their own is a very important factor [START_REF] Harder | Möglichkeiten der mobilität blinder menschen[END_REF]. Various apps are available to support this user group, but not every app provides an accessible user interface. The innovative part of the empirical work in this contribution uses MDD to generate accessible apps. With the help of a meta model a concrete model of an transportation app is designed. Several features and workflows for the domain of transportation apps are included in this model. For example, most transportations apps need the functionality to fetch the current GPS position, which is part of the meta-model. Specifying getposition (see Section 3.1) in the model adds to appropriate code to the app. With an instance of this model an app scaffold is generated.

Based on best practices for accessible apps (see [START_REF] Krajnc | User centered interaction design for mobile applications focused on visually impaired and blind people[END_REF][START_REF] Krajnc | A touch sensitive user interface approach on smartphones for visually impaired and blind persons[END_REF][START_REF] Barnett | Bootstrapping mobile app development[END_REF][START_REF] Mattheiss | Route descriptions in advance and turn-by-turn instructions-usability evaluation of a navigational system for visually impaired and blind people in public transport[END_REF]) and the adoption of common standards (see [START_REF] Caldwell | Web content accessibility guidelines (WCAG) 2.0. W3C recommendation[END_REF][START_REF] Patch | Mobile accessibility: How wcag 2.0 and other w3c/wai guidelines apply to mobile[END_REF]) required accessibility features are included from the beginning.

App programmers open the generated sources in the development environment (IDE) and can focus on the business logic which is not generated automatically. The resulting app has a simplified workflow and an accessible user interface (see screenshot in in Fig. 2).

Model

Concerning the model, we choose a domain specific approach. Which leads to a very specific and a straightforward model. We choose the domain of mobility and transportation apps. These kinds of apps help visually impaired, and disabled people to be more independent while travelling. For this reason a research on common transportation apps was necessary.

Transportation apps like Google Maps, OSM Routing or apps from different public transport companies have similar features. These are: -Fetching your actual position -Entering a target location -Searching for a location -Showing a route -Display a map -Receiving infos from public transport These features and workflows within an app are defined in a model. With a defined notation developers are able to build the the scaffold of their own transportation app.

Modeling Language

Domain Specific Languages (DSL) help you to describe a model in your domain [START_REF] Fowler | Domain-specific languages[END_REF]. In this work an internal DSL is used. The language definition and the dedicated models are written in XML. We choose XML, because there are various tools available to create and process XML-based languages. But in the end it is more the less a personal decision, which language you use [START_REF] Fowler | Parserfear[END_REF]. For better usability and non programmers a visual editor to create the model based on this DSL would be helpful.

Example of an GPS position finder app:

<?xml version="1.0" encoding="UTF-8"?> <app appname="whereami" package ="at.fhj.modeling"> <screen name="startscreen" transition="mainscreen"> </screen> <screen name="mainscreen" transition="back" > <action function="getposition"> <input type="button"/> <outout type="text"/> </action> </screen> </app>

App Accessibility

People with special needs are nowadays able to operate standard computers without great difficulties. With the help of, for example, a braille display and build-in features of an operating system a visually restricted person can perform tasks on a PC. Visually impaired and blind people where also used to handle key-based mobile phones with screenreader software as add-on. With the uprise of touch-based smartphones these users had to find new ways of interaction.

On the popular mobile platforms iOS and Android are already some accessibility features included. The VoiceOver2 system on iPhone allows a blind person to use a smartphone. On the Android platform TalkBack3 is the integrated accessibility feature to react the user's touch input to voice output. But both systems can only provide an accessible user experience if an app is created properly. Developers have to follow the guidelines for iOS [START_REF]Apple: Accessibility on ios[END_REF] or for Android [START_REF]Android: Accessibility -usability -google design guidelines[END_REF]. Both platforms have some similarities but have also some big differences.

The Web Accessibility Initiative (WAI) of the W3C provides standards to improve accessibility for the Web. The actual standard for web applications is WCAG 2.0 [START_REF] Caldwell | Web content accessibility guidelines (WCAG) 2.0. W3C recommendation[END_REF] this guideline is based on general principles for accessible development rather then technical solutions. Therefore this standard provides a basis for non web solutions as well. Relevant principles of WCAG 2.0 [START_REF] Caldwell | Web content accessibility guidelines (WCAG) 2.0. W3C recommendation[END_REF] are:

-Perceivable -Operable -Understandable -Robust These principles are relevant to modern web applications but can be applied to non-web contents like mobile applications.

Currently a first public draft for a new standard for mobile accessibility [START_REF] Patch | Mobile accessibility: How wcag 2.0 and other w3c/wai guidelines apply to mobile[END_REF] is available. This document describes how the principles and guidelines of existing standards like WCAG 2.0 can also be applied to native mobile apps.

In an (semi-) automatic generation process we have to consider platform independent principles and also platform related source code enhancements.

App Generation

With the model specified in Section 3.1 we are now able to generate an app scaffold for accessible transportation apps. This step, also known as transformation [START_REF] Völter | Model-driven software development: technology, engineering, management[END_REF], is handled by a chain of tools. The first one in this chain is JAXB [START_REF] Ort | Java architecture for xml binding (JAXB). Sun Developer Network[END_REF], whose task is to read the XML file and transform it into Java objects. Having the information stored in objects allows now to use it in combination with the Android command line tools to create an Android project scaffold. After this we are triggering a templating engine which generates the files, which are needed for the structure specified in the model. The process from XML-based model to a final app is illustrated in Fig. 3.4. The previous step also includes the mentioned accessibility features which are noticed in the Section 3.3. The outcome from this transformation process is an app scaffold with accessibility features. All required app components (e.g start-activitiy) and libraries (e.g. routing-lib) are available in the app project. Further product flavours can be integrated in the app's source code. Features like content description for integrated screen reader support or active voice output in selected parts of the app are automatically generated.

Conclusion

In this paper we describe the combination of the topics accessibility, mobile apps and model-driven development. In the Section related work we looked at the intersection of these domains.

In the empirical part of this work we build a meta-model for the domain of transportation apps. With an instance of this model one can create a appscaffold for accessible transportation apps. In the model-transformation process all main-screens, workflows and platform related accessibility features are produced. Developers can focus on the app features, because accessibility is build in from the beginning.

Further work will be the improvement of this concept concerning the utility and usability of the model generation and transformation.

Fig. 1 .

 1 Fig. 1. The research focus is in the intersection of Model Driven Development (MDD), Mobile App Development, and Accessibility.

Fig. 2 .

 2 Fig. 2. Screenshot of the resulting routing app.

Fig. 3 .

 3 Fig. 3. Workflow from Meta-Model to Model to App Scaffold to final App.

http://www.smartinsights.com/mobile-marketing/ mobile-marketing-analytics/mobile-marketing-statistics/

http://www.apple.com/accessibility/ios/voiceover/

http://www.google.com/accessibility/on-the-go.html

Acknowledgments

This work was funded by the Austrian research funding association (FFG) under the scope of the program Mobility of the Future within the research project PONS.


Hermann Kaindl

Thomas Rathfux

Bernhard Hulin

Roland Beckert

Edin Arnautovic

Roman Popp

Hermann Kaind

A Core Ontology of Safety Risk Concepts

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

In the context of our overall eort to support reuse in safety risk analysis (see, e.g., [START_REF] Kaindl | Towards reuse in risk analysis based on product line requirements[END_REF], we have been working on tool support. Such a tool needs to allow for input, handling and storing information on concepts like Hazard. Our chosen approach to generate parts of such a tool using Eclipse, a related metamodel has to be dened. So, we looked up standards and related scientic literature to gather information for such a metamodel. Unfortunately, we found inconsistencies between the terminology of the standards with conceptual models in the literature. In addition, we could not nd any conceptual model in the literature that would cover the core concepts comprehensively.

In particular, we investigated this issue in the context of automobiles and railway vehicles. In general, all such vehicles are covered by the generic standard IEC 61508 [START_REF]Functional safety of electrical/electronic/programmable electronic safety-related systems[END_REF], which has the scope of Electrical / Electronical / Programmable Electronic Safety-related Systems (E/E/PE) and is based on ISO/IEC Guide 51 [START_REF]ISO/IEC Guide 51 -Safety aspects Guidelines for their inclusion in standards[END_REF]. For practical reasons, more specic standards apply:

ISO 26262 [START_REF]Road vehicles Functional safety[END_REF] for automobiles, and EN 50126 [START_REF]EN 50126-1, Railway applications The specication and demonstration of reliability, availability, maintainability and safety (RAMS). Part 1: Basic requirements and generic process[END_REF] & TR 50126-2 [START_REF]Railway applications The specication and demonstration of reliability, availability, maintainability and safety (RAMS). Part 2: Guide to the application of EN 50126-1 for safety[END_REF] for railway systems Fig. 1. Taxonomy of standards under investigation Figure 1 depicts the relationships between these standards in the notation of the Unied Modeling Language (UML) [START_REF] Rumbaugh | The Unied Modeling Language Reference Manual[END_REF], see omg.org for the current version.

The arrow head points from the specic standards to the more general one (IEC 61508), which is also associated with ISO/IEC Guide 51.

ISO/IEC Guide 51:2014 [START_REF]ISO/IEC Guide 51 -Safety aspects Guidelines for their inclusion in standards[END_REF] provides requirements and recommendations for the drafters of standards for the inclusion of safety aspects. This standard is applicable to any safety aspect related to people, property or the environment, or to a combination of these.

ISO 26262 is the functional safety standard for road vehicles and is derived from the generic functional safety standard IEC 61508. It deals with the possible hazards that could result from function failure in the electrical/electronic system in automotive vehicles.

EN 50126 is relevant for the whole railway system and not limited to railway vehicles. In contrast to IEC 61508 and ISO 26262, the railway standard EN 50126 is not limited to hazards resulting from malfunctioning of E/E/PE. Primarily based on the terminology of these standards as dened in their glossaries, we started modeling of what we consider the core safety concepts. In addition, we employed tool support for nding relations between these concepts.

In the course of several iterations over model versions in meetings, the models were most importantly extended and rened by expert knowledge from both the automotive and railway domains. We present here the resulting core ontology.

While it may have various applications in practice as a reference model in the future, we already used it for a preliminary but systematic study on where human error may compromise safety. This involved both traversing the graph of ontology concepts and looking at it as a whole.

The remainder of this paper is organized in the following manner. First, we motivate our work explicitly and discuss related work in the scientic literature.

Then we elaborate on our eort on conceptual modeling of terminology from standards. Based on that, we explain our resulting core ontology of risk concepts.

In addition, we sketch its t into an upper ontology. As a possibility to make use of our ontology, we sketch how human error may compromise safety.

Motivation

While we originally strived for a metamodel for our tool support, our motivation for creating such a core ontology soon became more fundamental. In fact, safety assessment is in many ways subjective, partly because of individual risk perception, experience, education, cultural pressure and habits.

To reduce the arbitrariness of safety assessment, experts dened safety concepts such as Risk, Hazard and Accident. However, denitions in natural language are inherently ambiguous. With an ontology, at least the relations among the concepts contained can be made precise. They can also be visualized in gures as shown below, and such gures can support a common understanding of safety concepts.

In addition, even the denitions of safety core concepts such as Risk are not consistent between dierent safety standards. For example, while it is dened in the ISO 26262 standard [START_REF]Road vehicles Functional safety[END_REF] for the automotive domain as combination of the probability of occurrence of harm and the severity of that harm, for the railway domain it is dened as the rate of occurrence of accidents and incidents resulting in harm (caused by a hazard) and the degree of severity of that harm [START_REF]Railway applications The specication and demonstration of reliability, availability, maintainability and safety (RAMS). Part 2: Guide to the application of EN 50126-1 for safety[END_REF]. For creating our core ontology, we made an ontological decision in favor of the former denition, since it is actually derived from the ISO/IEC Guide 51 [START_REF]ISO/IEC Guide 51 -Safety aspects Guidelines for their inclusion in standards[END_REF].

Being precise and consistent in this regard is actually a major concern in practice. This was, for instance, a major lesson learned by the author of this paper who is a safety expert in the railway domain, in an international project for the installation of a people mover. According to this real-world experience, if understandable and consistent denitions are not introduced in an early project phase, later much time will be wasted with discussions and with the reformulation of documents for the safety case.

Moreover, the consistency of denitions of safety concepts may become important after an accident in legal courts. Interpretations of safety concepts may be discussed there and related questions raised, such as the following:

What was the interpretation of the safety concept x for the safety case? What are other interpretations of this safety concept (in the standards used or other similar ones)?

Would the other interpretation have led to additional safety requirements? Could the accident have been avoided if such additional safety requirements were taken into account?

Our core ontology of safety risk concepts may help to answer such questions consistently.

3 Related Work in the Literature Ambiguity of safety standard terminology and the problems resulting are discussed in [START_REF] Hogganvik | Risk analysis terminology for IT-systems: does it match intuition?[END_REF][START_REF] Schnieder | Railway safety and security two sides of the same coin?![END_REF]. Models of safety standards can contribute to avoid misunderstandings and conicting views on the concepts behind the terminology. Such a model for IEC 61508, with the focus on creating a chain of evidence for safety compliance demonstration, is proposed in [START_REF] Panesar-Walawege | Characterizing the Chain of Evidence for Software Safety Cases: A Conceptual Model Based on the IEC 61508 Standard[END_REF]. Unfortunately, as explained below, there are ontological problems with this model, in particular its Risk concept. Another model of a few concepts from ISO/IEC Guide 51, from which IEC 61508 takes many of the core glossary denitions, can be found in [START_REF] Schnieder | Railway safety and security two sides of the same coin?![END_REF]. It only centers around a model of Risk, but also this model has ontological problems as explained below. Hence, we could not base our core ontology on either of these papers.

A discussion of evolving denitions of the concepts Risk, Hazard and Mishap in military standards is discussed in [START_REF] Zhao | An event-chain risk assessment model based on denition evolution in safety criterions[END_REF]. As a result, a formalized model for calculating hazard and mishap occurrence probabilities is presented. The ontological view of risk-related concepts in these military standards is quite dierent from the one in automotive and railway standards. Hence, it was not possible to base our core ontology on this work, either. However, the increasing importance of the Mishap concept in the evolution of military standards suggests to us the importance of the related Accident concept. As explained below, the inclusion of Accident into our core ontology was only in the course of an evolution of our conceptual models.

The closest attempt to our ontological modeling in this paper can be found in [START_REF] Hulin | Towards a Common Safety Ontology for Automobiles and Railway Vehicles[END_REF], where we focused on the dierences in automotive and railway standards and unied them conceptually as far as possible. In contrast, the current paper provides a core ontology of the common safety concepts. In addition, there was no model of Risk yet in [START_REF] Hulin | Towards a Common Safety Ontology for Automobiles and Railway Vehicles[END_REF].

Our development of a core ontology of safety risk concepts may be considered as a simple application of Ontology Engineering (OE) [START_REF] Fernandez-Lopez | Methontology: from ontological art towards ontological engineering[END_REF]. OE represents the set of activities that concern the ontology development process, the ontology life cycle, and the methodologies, tools and languages for building ontologies ( [START_REF] Gómez-Pérez | Ontological Engineering: With Examples from the Areas of Knowledge Management, e-Commerce and the Semantic Web[END_REF], as cited in [START_REF] Simperl | Ontology Engineering: A Reality Check[END_REF]. Typical activities in OE are Domain Analysis and Specication (knowledge acquisition, and the denition of ontological purpose, including its use cases, users, etc.), Conceptualization (structuring of domain knowledge), and Implementation (expressing the ontology using an appropriate ontology representation language). On top of the activities for ontology building are the activities for ontology utilization and application (e.g., building tools for the dened use cases). Another important activity in OE is ontology evaluation. The goal of ontology evaluation is to estimate the quality of the ontology, and it includes ontology validation (investigation if the ontology represents the real-world domain concepts and their relationships appropriately, and if it fullls the ontology use case and purpose), and verication (proving consistency and that the ontology is correctly constructed according to the language used, etc.) [START_REF] Hajdu | Selected papers from creative construction conference 2014 ontology evaluation: An example of delay analysis[END_REF]. However, most of the ontology evaluation approaches [START_REF] Brank | A survey of ontology evaluation techniques[END_REF] deal with large, complex and more or less formally represented ontologies (e.g., in OWL or description logic) and are not suitable for our case.

Since we have used a semi-formal representation in UML without constraints, logic formalisms, etc., and having in mind the current size of our core ontology, explicit ontology verication is not feasible. Regarding validation, we iteratively reviewed the results from ontology development steps using expert knowledge.

In our future work, we plan to validate the ontology against use cases. Another option for ontology validation would be to automatically create an ontology from standards and (or) scientic literature and qualitatively compare it to our manually created ontology. Sfar et al. [START_REF] Sfar | Gold standard based evaluation of ontology learning techniques[END_REF] use a similar comparison to evaluate automatically created ontologies against a gold-standard ontology created by humans. So, using ontology learning [START_REF] Wong | Ontology learning from text: A look back and into the future[END_REF] for the validation of our core ontology would be a valid goal for our future research. We already gained rst experience in comparing semi-automatically created taxonomies (light-weight ontologies) to manually created domain models in requirements engineering [START_REF] Casagrande | Semiautomatic system domain data analysis: A smart grid feasibility case study[END_REF].

Conceptual Modeling of Terminology from Standards

Conceptual modeling is, in general, not that simple. Regarding models of safety concepts in the literature, we particularly found inconsistencies in [START_REF] Schnieder | Railway safety and security two sides of the same coin?![END_REF] and in [START_REF] Panesar-Walawege | Characterizing the Chain of Evidence for Software Safety Cases: A Conceptual Model Based on the IEC 61508 Standard[END_REF]. In both cases, these are supposedly related to misunderstandings of the aggregation relationship of UML.

In [START_REF] Schnieder | Railway safety and security two sides of the same coin?![END_REF], a categorization of the concept Risk is correctly modeled using generalization of the classes representing the subconcepts in UML. However, Damage (supposedly used here as a synonym of Harm) is modeled there as an aggregation of three special cases of Harm, and this should rather be modeled as well using generalization.

In [START_REF] Panesar-Walawege | Characterizing the Chain of Evidence for Software Safety Cases: A Conceptual Model Based on the IEC 61508 Standard[END_REF], the concept Risk is modeled as class with a few UML attributes, including likelihood and consequence. Assuming that they correspond to Probability and Severity according to the standards that we model below, there is an interesting modeling issue. In the specication of UML, an attribute is said to be semantically equivalent to a composition association. When considering this statement more precisely, the question arises, in which sense an attribute is part of an object. In the UML metamodel, attribute is part of class in a composition.

In this sense, an attribute is an entity of its own, which denes UML. But in the specication of UML as well as in [START_REF] Rumbaugh | The Unied Modeling Language Reference Manual[END_REF], attributes are also said to be composition relationships between a class and the classes of its attributes. In this sense, an attribute would model the same relationship as a composition. A simple example shows that this view is questionable. The region of a wine can be modeled as its attribute (as one of possibly several), but this does not mean that any particular region is part of a particular wine. Already in [START_REF] Winston | A taxonomy of part-whole relations[END_REF], attribution was said to be often confused with a whole-part relationship. The argument that these are dierent relationships was another simple example: While towers have height as one of their attributes, height is not a part of a tower. Therefore, it is rather the class representing the concept Harm that may have (among others) the attributes Probability and Severity, see Figure 2. While we think that this is a `true' model of these concepts (according to the standards under consideration), this way of modeling raises yet another issue. How would it be possible in such a model to represent that this combination of Probability and Severity of Harm is Risk? All this justies the ontological decision to model this inner core as given below (using aggregation). For the actual modeling involved for achieving our proposed core ontology, we pursued two dierent ways. We employed tool support for getting automated suggestions for association relationships, and we had a series of expert meetings, i.e., meetings involving two safety experts. Note, that the tool run was only after the second of a total of four meetings. So, it was not intended to bias the whole eort but only to see more exactly what can be extracted directly from the given glossaries.

Tool-supported Modeling

After the second meeting (as sketched below), we tried tool-supported modeling. We were interested in getting suggestions for (binary) association relations between any two of the core concepts under discussion in the meetings, based on their glossary denitions in the standards under investigation. Our major interest was to see what exactly these denitions say about potential relations between the concepts dened.

More precisely, we employed the tool RETH (Requirements Engineering Through Hypertext), a tool for requirements specication according to the method with the same name. RETH combines object-oriented technology and hypertext. It was developed under the guidance of the rst author of this paper some time ago, see, e.g., [START_REF] Kaindl | A practical approach to combining requirements denition and objectoriented analysis[END_REF].

For tool-supported modeling in the course of creating our core ontology of safety risk concepts, we used the RETH tool to automatically generate glossary links, see [START_REF] Kaindl | Semiautomatic generation of glossary links: A practical solution[END_REF]. More generally, it is a semi-automated generation that allows the user to reject a suggested link, but we refrained from this option in order not to inuence the result. Based on such links, we let the tool automatically generate (binary) association relations in a second step, see [START_REF] Kaindl | How to identify binary relations for domain models[END_REF]. According to the heuristic behind that, RETH simply generates an association, if and only if there is a glossary link in either direction. Of course, such proposed associations can be deleted manually, e.g., if they are transitive and, therefore, may be considered redundant. Again, we refrained from this option in order not to inuence the result. Note, that this tool can also propose generalizations, e.g., for Risk being more general than Individual Risk (based on an obvious linguistic clue), but we did not have such a case here. Let us show an example of an entry for a concept and its denition as an excerpt from a linearized tool output: The link to harm was already given in this standard, but not the one to severity, which was generated by the tool. The associations in this case only correspond to out-going links from this concept and are shown here through a generated name and a link to the associated concept.

The resulting model from the tool run is shown in UML in Figure 3. With respect to our inner core of concepts around the concept Risk, the association A-2 is a typical case of a redundant transitive relation, which can be deleted in order not to clutter the diagram. A-0 and A-1 are simply shown here as associations, while they may be modeled as their special case of an aggregation in UML. However, the tool does not have any clue for such a distinction. (Note, that the UML denition of an aggregation is vague, and attempts to formalize them in logic are dicult.) An interesting observation is that the concept Accident is shown here in isolation, i.e., without any association relation with any of the other concepts of this model. Hence, let us have a look at its denition: Accident Source of Denition EN 50126-1 an unintended event or series of events resulting in loss of human health or life, damage to property or environmental damage In fact, there is no link that could have been found by the tool, while this text can be interpreted in such a way that Accident may be related to Harm. This concept is directly associated in the model with the concept Hazard, however, based on the following denition: Hazard Source of Denition ISO 26262-1 potential source of harm caused by malfunctioning behaviour of the item A-4 Harm A-6 Malfunctioning Behaviour A-7 Function

The reader is encouraged to compare this model with the ones created and elaborated at the meetings as sketched below, especially regarding this direct association. Note, in addition, that the concept Malfunctioning Behaviour was nally not included into our core ontology, although it would make sense, but it seemed to be less important in the standards under investigation.

Expert Meetings

As indicated above, we had four expert meetings including two safety experts, one primarily in the railway domain, the other in automotive. The other participants have primarily background in software and symbolic modeling, in particular also on ontologies. Note, that all participants of these meetings are also authors of this paper. Each meeting had ve to six participants, and the duration was, on average, approximately seven hours. Between these meetings, we aligned ourselves via email and telecommunication, while we primarily worked on dierent tasks.

The starting point was a metamodel intended to create an Eclipse-based tool for supporting reuse of safety risk analyses. This metamodel included among other classes for requirements, etc., the following ones: Function, Failure, Hazard, Severity and Tolerable Hazard Rate (see also [START_REF] Kaindl | Towards reuse in risk analysis based on product line requirements[END_REF]).

Since this metamodel was considered insucient by these authors, the relevant standards were consulted, rst IEC 61508 and ISO Guide 51. Since the Fig. 4. White board with sticky notes from second meeting terms in these standards are not unambiguously dened, we decided to look for conceptual models that we could adopt for the metamodel needed. Unfortunately, as explained above, we could not nd a comprehensive model of the core safety terms as needed in the scientic literature. It even contained conceptual models that are inconsistent with the terminology of these standards.

In the course of a rst meeting of all the authors, we primarily discussed an integration of a Risk model with the concepts corresponding to the classes of our previous metamodel. Immediately after this rst meeting, however, the safety expert of the railway domain criticized that Accident was missing in our model and pointed to the denition according to EN 50126. Additionally, he proposed to introduce Hazardous Situation for representing preconditions that could lead to an Accident.

In our second meeting, we discussed possible inclusions of these concepts into our model. Even though neither IEC 61508 nor ISO 26262 dene Accident explicitly, we decided to extend our model with this concept. In order to determine reasonable associations between the given concepts, we used sticky notes with a concept name per note, and arranged them on a white board (for the result see Figure 4). As shown above, an association between Accident and Harm is obvious, but what causes the occurrence of such an unintended event? The denitions do not clarify that. So, the safety experts' knowledge was brought in and Between the second and the third meetings, we used the RETH tool as explained above. While the resulting model is fairly similar to the one after our second meeting, the tool could not nd any association of Accident with the other concepts.

In the third meeting, we examined the association between Hazard and Accident more closely. In particular, we took ISO 26262 into account, which denes Hazardous Event as the combination of a Hazard and an Operational Situation. According to the glossary denitions, there is a missing link between Hazard and Accident, because an Accident is a result of a single event or a series of events. After long discussion, we erroneously decided to add both the concepts Hazardous Event and Accident as one named Hazardous Event / Accident due to their apparent similarity, resulting in the conceptual model given in Figure 5.

After even more discussion in the course of the third meeting, we split Hazardous Event and Accident, and dened an association named may cause between them.

In the fourth meeting, we reviewed the resulting model from the third meeting and did not nd a aw, while there are always options for other ontological decisions. The only change was adding Triggering Event, with an association named triggers with Accident. This model intends to reect that both Hazardous Event and Triggering Event are preconditions of an Accident.

Our Core Ontology

The resulting conceptual model is shown in Figure 6. We consider it as a core ontology of safety risk concepts. While our sketch of its evolution above should already serve as an explanation, a few more explanations are still necessary for the rationale of some of its parts.

The ontological decision for the aggregation of Risk (instead of attributes) is explained above in detail. Such an aggregation relation in UML is shown as Fig. 6. Resulting conceptual model dening a core ontology of safety risk concepts a diamond, see Figures 5 and6. The rationale for the aggregation of Hazardous Event is by analogy. In fact, both underlying denitions in the standards use the same formulation combination of .

The name of the association between Accident and Harm, results in, suggests that every accident results in harm. Otherwise, this unintended event or series of events would not be considered an accident according to the denition of in EN 50126 (see also above). Instead of naming it may results in, which somehow involved yet another probability, our railway expert suggested to assign Severity 0 in case there is no resulting human Harm. In this way, our model resolves the very narrow and conicting denition of Harm in the ISO 26262 standard, which is restricted to human health but not to goods or the environment.

The concepts Function and Failure are only relevant for `Functional Safety', i.e., when assessing Harm based on analyzing potential failures of each function of a system. This has to be done according to ISO 26262 in the automotive domain. For other kinds of safety analyses, these concepts may be ignored.

Overall, this core ontology is an interesting combination of both the automotive and the railway domains. The concepts shown in blue are common, while the others are based on terminology from ISO 26262 and EN 50126, respectively.

Upper Ontology

For such an ontology, also its t into a so-called upper ontology is important.

Upper ontologies represent general concepts to be used for creating more specic domain ontologies such as ours. In this regard, let us focus on a specic problem.

In our meetings, we struggled with the terms Hazardous Situation and Hazardous Event. In fact, there is no clear conceptual dierentiation between the concepts Situation and Event in the standards that we used. To clarify this, we looked into several upper ontologies. OpenCyc [START_REF] Lenat | Cyc: A large-scale investment in knowledge infrastructure[END_REF] is the largest and the best known upper ontology, containing around 10 5 generic concepts. OpenCyc denes the concept of a Situation roughly as a state and as specializations of Intangible and Temporal concepts. Event is dened as a specialization of Situation (a dynamic situation in which the state of the world changes). Contrary to Event, in a Static Situation (as another specialization of the concept Situation), objects and their relations do not change over time. OpenCyc also denes the concept of DangerousSituation as a specialization of the Situation where a signicant risk of death, injury, or property damage exists. Even though these denitions are not precise enough for safety analysis (e.g., DangerousSituation has the word Hazard as a synonym, but the safety standards explicitly distinguish between these two concepts), it seems as though the conceptualizations of OpenCyc t well the intrinsic meaning of the safety-related concepts of our ontology.

Deeper investigation on the relation to other upper ontologies (e.g., ABC upper ontology [START_REF] Hunter | Enhancing the semantic interoperability of multimedia through a core ontology[END_REF], General Formal Ontology [START_REF] Herre | General formal ontology (gfo) : A foundational ontology for conceptual modelling[END_REF], or SUMO Suggested Upper Merged Ontology [START_REF] Niles | Towards a standard upper ontology[END_REF]) will be part of our future work.

Human Error

Human error may compromise safety in the context of safety-critical systems.

Let us sketch how our core ontology of safety risk concepts can be used for a systematic analysis of human error.

First, the graph of ontology concepts can be traversed systematically, where each concept is investigated regarding human error. In particular, additional hazards caused by human error are important. They may lead to additional hazardous events and accidents as well. With respect to user errors, e.g., especially the triggering events of accidents are of interest. Design and development errors as well as manufacturing, construction and installation errors seem to be more related to functions and related failures. Also maintenance errors are to be studied in this context.

With the help of the ontology, human error can be identied or classied systematically, see Table 1. The three concepts Function, Failure and Hazard at the left of Figure 6 are relevant for human error analysis if an operator or maintainer is involved in fullling or supporting a function, respectively. For example, a train driver of certain railway vehicles has to fulll part of the socalled Parking function. For the analysis of human error in such a case, the acting humans are considered part of the system. Such an analysis is especially important in degraded modes with more intensive use of human capabilities. In general, the traversal of the ontology guides from each instance of Function to analyzing it with regard to Failure and Hazard. This functional safety analysis has to investigate which failures may be caused by such a human error, and which hazards may result. Analogously to operator error, errors of maintainers can be analyzed in this way. For example, in a railway vehicle the generation of pressurized air is safety-relevant, since many functions such as braking are implemented based on it. Filtering of dust and dirt in the pressurized air is a crucial point, since air pipes may become locked by dust and dirt. Hence, the dust lters have to be changed after at least one year. If this does not happen, e.g., caused by human error in maintenance, these lters will lose their required function. Aected persons of operator errors can, of course, be the operator who caused the hazard, but also others, such as passengers of a train. Related to persons at risk, i.e., all involved humans that may suer Harm from a given Hazard, the concepts Hazardous Event and Accident are particularly important for the analysis of human error. Their instances need to be analyzed especially regarding possibilities for escaping or avoiding any instances of Harm, e.g., through self rescue, and what kind of human error may happen in this course. The avoidance of harm must be recognizable, understandable, possible and desirable. For example, in case of large and abnormal vibrations in a wagon of a train, pulling the emergency brake may be the most appropriate action to be taken by a passenger. However, there are some problems involved in such a situation. First of all, the passenger needs to recognize that these vibrations are abnormal. Given that, the passenger has to understand that it is reasonable or necessary for him or her to act. In addition, the passenger needs to gure out which actions are possible, e.g., pulling the emergency brake or moving to another part of the train. Finally, the passenger needs to judge that such an action is desirable, since unjustied pulling an emergency brake is also subject to being punished, and decide to actually perform such an action. In particular, such an analysis of human error needs to take into account that humans involved in an accident are usually under stress, and the more stressed humans are the more likely they commit errors.

The concept of a Triggering Event related to an Accident is relevant in the context of unintended or intended misuse. An example of a triggering event is pushing the button for opening doors of a train during the Operational Situation in a tunnel at high speed (say, 300km/h). In such a situation, the aerodynamic forces can be strong enough to pull a passenger out of the train if a door in the vicinity opens. This human error of misuse is covered by electronic locking of the doors, where unlocking a door in such a situation would be an instance of Hazard.

Such a systematic of human error may, in turn, suggest an integration of additional technical assistance systems. These are intended to reduce the possibilities of human error or its negative eects. The overall safety assessment needs to nd a balance between human and technical aspects related to hazards and risks.

Another potential use of our core ontology related to human error is to look at it as a whole. After all, it is currently fed into a tool for supporting reuse of risk analyses (through a related metamodel). When risk analyses with all the related information according to our model will be reused for similar cases, e.g., previous hazards will be taken into account that otherwise may be overlooked by human error.

Even regarding standards, both their creation and their application, there is some potential use of our core ontology. After all, it is based on ISO 26262, EN 50126 and IEC 61508. Problems often arise from contradicting or arbitrary denitions, or even missing denitions. For example, in ISO 26262 the term accident is not dened even though it is used in some of its parts. For the creation of future (versions of ) standards, human error may be reduced through this and enhanced ontologies.

Conclusion and Future Work

Primarily based on the glossaries of standards for automotive and railway, we created conceptual models, both using tool support and in a series of expert meetings. Especially in these meetings, of course, expertise of two safety experts played a major role in the evolution of these models. We consider the resulting model a core ontology of safety risk concepts covering both domains, which also ts into a major upper ontology. As a preliminary application of this core ontology, we used it for systematically studying possibilities of human error compromising safety.

In on-going and future work, we base a corresponding metamodel for tool creation using Eclipse on this core ontology. This metamodel will also include requirements-related concepts, which we have sucient previous experience with.

Using the resulting tool, and indirectly our core ontology, we will perform case studies, focusing on reuse of risk analyses. In this course, we will particularly investigate whether this reuse can help to reduce human error of omitting important information on previously known hazards, etc. All this will be important for the sake of validation of our proposed approach. Also extending the scope, e.g., to avionics or healthcare will be of interest.

Fig. 2 .

 2 Fig. 2. Harm class with attributes

Fig. 3 .A

 3 Fig. 3. Conceptual model with tool-generated associations

Fig. 5 .

 5 Fig. 5. Conceptual model in the course of the third meeting

Table 1 .

 1 Classication of human error related to concepts of the ontology.

	Role of human Related concepts	Possible reason
	Operator Maintainer Person at risk Hazardous Event, Accident Self rescue Function, Failure, Hazard Operator involved in Function Function, Failure, Hazard Maintainer supporting Function User Triggering Event, Accident Misuse

Acknowledgment

Part of this research has been carried out in the RiskOpt project (No. 845610), funded by the Austrian BMVIT (represented by the Austrian FFG).


Luca Balvis
email: luca.balvis@unica.it

Ludovico Boratto
email: ludovico.boratto@unica.it

Fabrizio Mulas
email: fabrizio.mulas@unica.it

Davide Lucio
email: davide.spano@unica.it

Salvatore Spano
email: salvatore@unica.it

Gianni Carta

Fenu
email: fenu@unica.it

Keep the Beat: audio guidance for runner training

Keywords: Audio guidance, Beats, Running, Training, Evaluation, Fitness

Understanding how to map the feedback by fitness apps into concrete actions during the exercise performance is crucial for their effectiveness, for both inexperienced and advanced users. In this paper we focus on audio feedback for running, describing a beat-rhythm representation of the target cadence for helping the user in keeping it. We designed the feedback system in order to balance two conflicting objectives: its effectiveness in helping the user in reaching the training goal and its intrusiveness with respect to concurrent activities (e.g., listening to the music). We detail how we track the user's cadence through standard smartphone sensors, how and when we generate the audio messages. Finally, we discuss the results of a user-study, showing effectiveness with respect to the adherence to the exercise goal and the overall usability.

Introduction

Smartphones have embedded sensors of increasing quality through the years, which quickly substituted entry-level devices for different tasks, such as e.g. taking pictures, videos, recording audio, browsing the internet. In particular, inertial sensors (accelerometers, gyroscopes, compass) and GPS receivers constituted the basis for the entry level activity tracker, which is now represented by different smartphone apps. The activity tracker applications are now spread also among the entry-level users, since they are very cheap, if compared with professional devices and applications.

Opening the market to such kind of users is a big opportunity for fitness application providers, but it is also a big challenge: the design of dedicated devices was targeted to professional users, which need many precise measures they are able to interpret directly. Many app users are not experts instead, so they would need a more intuitive representation of the tracked data.

If we focus on the information needed during the exercise, this is even more difficult: the user not only has to understand what the tracked data means, but she has also to take decisions based on such data for continuing the session. In this paper we consider the running activity as an example of the latter case: while running, the user should keep a target cadence, and smartphone applications help her tracking and reporting its current value. During the training, the application cannot rely on the visual channel, so audio messages are usually preferred. However, many runners are used to listen to the music or other entertainment content that may require the audio channel (e.g., audiobooks). Therefore, it is important for the feedback system to provide the relevant information without prevent the user to carry-out such entertainment activities and taking the complete control of the audio channel [START_REF] Terry | Effects of synchronous music on treadmill running among elite triathletes[END_REF][START_REF] Waterhouse | Effects of music tempo upon submaximal cycling performance[END_REF].

Considering the information the system provides to the user, reporting the current cadence is useful, but what if its value is not in line with the target? Entry-level users may have difficulties in mapping the application reported difference between the target and the current cadence into a concrete running action. Professional users have less difficulties in interpreting the values, however they still need to repeatedly check the measures and to take decisions accordingly.

In this paper we describe a generic audio feedback engine for runners, whose architecture allows providing adaptable audio feedback, exploiting the audio channel only when needed. It is possible for designers to control the number and the type of the generated feedback messages, while users may override the notification frequency in order to fine-tune it to their needs. The feedback system relies only on built-in smartphone hardware for tracking the activity. We describe the software component that senses the user's cadence, together with the rule system that decides how and when the application generates the audio messages. We detail how we configured it for providing a beat-rhythm representation of the correct cadence, which helps the user in keeping the target for the current training. In order to keep it unintrusive, the beats are played only if the user is running out of range.

Finally, we provide the results of a user-study having a twofold objective. The first one was to compare the effectiveness of the beat feedback in helping the user in keeping the target pace, comparing it to providing natural language messages. The second goal was to collect a qualitative data on different usability dimensions for the proposed feedback, showing both a very good perceived precision and completeness for provided information.

Related work

Mobiles have been used as activity trackers even before they were equipped with inertial sensors [START_REF] Consolvo | Activity sensing in the wild: A field trial of ubifit garden[END_REF]. Since then, the tracking techniques have evolved and now it is possible to track the user's steps with a good level of precision using inertial sensors such as accelerometers [START_REF] Tomlein | Advanced pedometer for smartphone-based activity tracking[END_REF] or gyroscopes [START_REF] Jayalath | A gyroscopic data based pedometer algorithm[END_REF], which are included in majority of smartphone models nowadays. For tracking the user's cadence, we built our prototype on top of such approaches, as many other commercial apps.

Even though several academic studies have been performed to support users in their running activities, finding applications that work in the real world and have an audio support is rarer. The three platforms that involve most users, i.e., Endomondo1 , Runtastic2 , and Nike+3 , all offer a form of audio support in which it is possible for the user to let the application read statistics when she covered a given distance or a specific amount of time has passed. These statistics involve common information, such as the average pace, speed, calories burned, heartbeat, etc. A form of support that provides the user with indications about the speed is provided by u4fit (previously known as Everywhere Run) [START_REF] Mulas | Everywhere run: a virtual personal trainer for supporting people in their running activity[END_REF]. Differently from the other applications, it checks the current pace of the user and compares it with the objective she had, and plays an audio support that tells the user to speed up or slow down.

The topic of providing effective audio feedback to users has been investigated under different perspectives in literature, especially considering mobile devices, which are often used while carrying-out different tasks. For this reason, different audio techniques have been developed for helping users in making selections without looking to the mobile screen [START_REF] Zhao | Earpod: Eyes-free menu selection using touch input and reactive audio feedback[END_REF]. Considering the particular application of audio feedback for providing guidance during physical activities, it is possible to find examples for different sports in literature. For instance, Nylander et al. [START_REF] Nylander | Swing sound: Experiencing the golf swing through sound[END_REF] created an audio feedback for guiding the user in reaching the highest point of acceleration just before hitting the ball. Stienstra et al. [START_REF] Stienstra | Embodying complexity through movement sonification: Case study on empowering the speed-skater[END_REF] used a sonification technique for guiding professional skaters with a feedback on their performance in real time.

Considering running applications, we can find examples of auditory feedback in different work in literature. MPTrain [START_REF] Oliver | Mptrain: A mobile, music and physiology-based personal trainer[END_REF] includes a set of sensing devices connected to a mobile phone, that are able to sense both the user's pace and physiological parameters, exploiting music for helping the user in achieving her goal. Our work focuses on built-in smartphone hardware and exploits an explicit feedback rather than on an implicit song selection. An evolution of this work, TripleBeat [START_REF] De Oliveira | Triplebeat: Enhancing exercise performance with persuasion[END_REF], introduced additional features like competition and a visual interface for motivating the user during the exercise.

Song playlists may be used as implicit feedback for helping users in keeping the target cadence. Indeed, music has different effects in the runner's performance, such as the synchronization of the cadence with the song tempo [START_REF] Terry | Effects of synchronous music on treadmill running among elite triathletes[END_REF] and an overall higher performance and less perceived fatigue [START_REF] Waterhouse | Effects of music tempo upon submaximal cycling performance[END_REF]. For instance, Rock-MyRun 4 is a commercial running application that selects songs from a playlist according to the user's hear rate, steps or target cadence, in order to increase the motivation and her performance. Even if this has been proven to be an effective support, it has two main drawbacks. Firstly, if the user is not willing to listen to the music during the exercise, she cannot receive the application feedback. In addition, it may happen that the user would like to listen to specific song that maybe do not match with the feedback requirements. In contrast, our feedback mechanism exploits the audio channel only when needed and not for the whole duration of the exercise.

PaceGuard [START_REF] Fortmann | Paceguard: Improving running cadence by real-time auditory feedback[END_REF] exploits a pulse feedback, similar to the one exploited in this paper, played during the whole exercise and adapted to the current user's performance. Differently from PaceGuard, we provide the audio feedback only if the cadence is out of range. In the meantime, other smartphone applications may use the audio channel (e.g., music players, voice calls). Considering smartphonebased applications, the audio feedback has been exploited for providing a remote support for encouraging users during races [START_REF] Woźniak | Rufus: Remote supporter feedback for long-distance runners[END_REF]. RunRight [START_REF] Nylander | Runright: Real-time visual and audio feedback on running[END_REF] creates a visual representation of the running movement using the acceleration on the vertical and horizontal axis. Similarly to the approach proposed in this paper, the system provides also a metronome for communicating the running cadence to the user, which changed randomly after a predefined amount of time. Our approach combines the information coming from the inertial sensors with the audio feedback for helping the user in reaching the training goal.

Audio support

In our work, we considered a scenario where the user should keep a target cadence, which is defined in advance according to the user's training goal (e.g., preparing for a competition) and the intensity not exceeding her capabilities. The target may be selected with the help of a trainer or by the user herself, but the application does not suggest it, since without heart-rate measures it would not be able to determine the correct intensity and this may lead to heart problems.

We designed the audio feedback support considering the trade-off between two aspects: the first one is the need to guide the user and to help her in keeping the correct cadence, while the second one is the intrusiveness of the support. On the one hand, sending messages each time we register a high difference between the current and the expected cadence guarantees the quickest possible user's reaction. On the other hand, if the user has difficulties in keeping the cadence, the feedback would be frustrating and it would take the complete control of the audio channel, preventing the users to perform other entertainment activities while running (e.g., listen to the music, radio or audio books).

Therefore, we designed a support able to adapt its behaviour to the user needs, which is configurable through different parameters, each one having a default value, which may be changed by the user for fine-tuning. The parameter set is the following:

-Sampling interval (i s ): the frequency for calculating the current cadence.

The default value is 1 minute. -Target cadence (k): the cadence that our user should keep during the current activity (or the current part of it), expressed in terms of steps per minute. -Tolerance. ( ): the number of steps per sampling interval that can be tolerated if a user is above or under the desired cadence, in order to consider her current cadence as correct. This allows us to define a tolerance range, as k ± . The default value is 5. -Feedback message duration. (t f ): the number of seconds the audio message should last. The default value is 15s. -Frequency of positive feedback messages ( 1 ip ): the number of minutes that should pass between an audio message and the next, when the user's cadence is correct. The default value for i p is 4 minutes.

-Frequency of negative feedback messages ( 1 in ): the number of minutes that should pass between an audio message and the next, when the cadence of the user is out of range.The default value for i n is 1 minute.

The audio feedback module contains two main components, separating the cadence tracking from the set of rules for generating the feedback messages:

1. Cadence analyser. This component analyses the current cadence of the user, in order to decide if it is correct, high or low. 2. Feedback manager. Given the decision of the cadence analyser and the current settings, this component decides whether a feedback message should be sent to the user and, if this is the case, it is responsible for creating it.

In the next sections, we describe in detail the two components.

Cadence Analyser

Given the current cadence of the user, i.e., the number of steps done in the last minute, this component determines if an audio message to support the user should be played, according to the constraints given as input to the application. It tracks the user's cadence exploiting the Step Counter Sensor5 provided with the default Android SDK, which internally exploits the accelerometers.

The cadence analyser component is a simple state machine, depicted in figure 1. It classifies the user's cadence into three classes, corresponding to its internal states:

1. Correct, when the user's cadence v is inside the target range k ± ; 2. High, when the user's cadence v is higher than the maximum of the range k + ; 3. Low, when the user's cadence v is lower than the minimum of the range k -;

The state transitions are defined through the value of ∆, which we calculate as follows (v is the current user's cadence) In each state, if ∆ = 0 the machine fires a transition towards Correct, if ∆ > 0 the next state is High, otherwise the next state is Low.

-if |k -v| < , then ∆ = 0; -if v > k + , then ∆ > 0; -if v > k -, then ∆ < 0; Correct start High Low ∆ = 0 ∆ > 0 ∆ < 0 ∆ > 0 ∆ < 0 ∆ = 0 ∆ < 0 ∆ > 0 ∆ = 0
Besides its internal state, the component exposes a variable ∆t, that tracks how long the machine is in the current state. This variable is increased of i s each time the machine fires a transition towards the same state and reset to zero each time the transition is towards a different state. The component raises an event each time a transition is fired, passing as arguments the current state s and ∆t.

Feedback Manager

The feedback manager component registers to the events raised by the cadence analyser, and it contains a set of rules for generating the audio feedback. In the current configuration, we included three rules, which we summarise in Table 1.

The first rule (line 1) triggers while the user is running for a long time (longer than i n ) at a high cadence (s is High). It resets ∆t to zero, renders a speech message for informing the user that her current cadence is too high, i.e. "Your cadence is too high. Try to follow this rhythm:" (line 3) and generates the beat feedback (line 4). The rules handling the other two cases, respectively low cadence (line 5-8) and current cadence (line 9-12) are similar: they render a different message through the text-to-speech, and we consider a different time in the correct case (i p ).

As already discussed while introducing the paper, we represent the cadence information as a rhythm, in order to allow the user to synchronize her steps with the beats. The PlayBeats procedure generates such feedback on the fly, creating and playing an audio stream containing a number of beat samples equally 1: upon event (s =High, ∆t > in) do 2:

∆t := 0 3:

Tts(DecreaseSpeedMsg) 4:

PlayBeats(k, t f ) 5: upon event (s =Low, ∆t > in) do 6:

∆t := 0 7:

Tts(IncreaseSpeedMsg) 8:

PlayBeats(k, t f ) 9: upon event (s = Correct, ∆t > ip) do 10:

∆t := 0 11:

Tts(OkMsg) 12:

PlayBeats(k, t f ) Table 1. Rules for triggering audio feedback in the Feedback manager module.

distributed in its duration. Such number n is obtained according to two parameters: the target cadence k and feedback message duration t f , as defined in equation 1:

n = 1 60 • k • t f (1)
The peak of each beat is positioned exactly in each n-th fraction of t f . The duration between two beats is filled with silence. The resulting message contains a simple click with the rhythm to be followed by the user. After t f seconds (15 by default), the audio channel is released by the feedback manager and it can be used again by other applications (e.g., the music player).

Discussion

We would like to point out here a set of relevant properties of the proposed audio feedback support. The first one is its flexibility: the separation of the two components makes it possible to provide different kinds of messages without changing the cadence tracking algorithm and vice versa. By maintaining the same communication protocol, it would be possible to exploit more sophisticated strategies for deciding if the cadence of our user is correct or not. The second important aspect is the possibility to configure the feedback messages through a set of rules, which may be defined differently by interface designers for increasing the effectiveness of the messages, and obtaining different types of feedback. As an example, we can consider the audio guidance provided by u4fit [START_REF] Mulas | Everywhere run: a virtual personal trainer for supporting people in their running activity[END_REF]. It exploits text-to-speech messages for informing the user in natural language, providing also quantitative information with messages such as e.g. "You're 10s per km slower, speed up!". Such messages may be easily generated modifying the rules in Table 1, using k-v as parameter for both the text to speech messages (increase ad decrease) and removing the calls to PlayBeats.

It would be possible to support a completely different feedback mechanism, such as for instance selecting a song from a playlist having a tempo that helps the user in increasing or decreasing her cadence, similarly to RockMyRun6 . According to the difference between the current and the target cadence (k -v), the rules in Table 1 would enqueue a song with a slower, faster or similar tempo for respectively decreasing, increasing and keeping constant the user's cadence.

The rules are also quite straightforward to understand even for users, if represented in natural language. This is very important, in order to enable the user's control over the feedback mechanism: if users have means for inspecting the rules and modify them (through guided procedures), it is more likely that they will be able to get the feedback they need. However, we are also aware that the large majority of the users are not willing to configure such aspects, therefore a good default mechanism is still crucial.

Finally, the parameters used for tuning the feedback and the run-time generation of the messages allows to exploit them in complex workouts, composed by different phases where the user should keep different cadences, or containing an adaptation of the target according to the current user's performance.

Evaluation

A user test has been carried out in order to evaluate the ability of the auditory support to guide the users in keeping a constant cadence during the workout, while maintaining the feedback unintrusive. Therefore, as baseline approach for providing feedback, we selected the approach among the currently available applications that we considered the most informative while keeping an unintrusive approach, which is the one used by u4fit. It exploits text-to-speech messages for informing the user in natural language, providing also quantitative information with messages such as e.g. "You're 10s per km slower, speed up!".

It is worth pointing out that the experiment setting is different from the studies by Terry et al. [START_REF] Terry | Effects of synchronous music on treadmill running among elite triathletes[END_REF] and by Waterhouse et al. [START_REF] Waterhouse | Effects of music tempo upon submaximal cycling performance[END_REF], since in these studies the music stimulus was available during the whole exercise, causing the reported synchronization effect. Instead, we provide feedback messages (either in natural language or through the beats), only when the user is out of range or, if the user is in range, we provide confirmation feedback at regular time intervals. We study the effectiveness of two different feedback types in this context.

Besides the comparative study, we included in the evaluation a set of qualitative aspects for understanding the overall user experience with the proposed support, in order to assess whether unintrusive feedback techniques are acceptable for users.

Test Design

In order to perform the comparison between the two feedback types, we created two different prototypes, one providing feedback through voice (V ) and one through the beats (B ). In the V condition we configured the rules for obtaining the feedback used in u4fit, while in the B condition we used the rules described in this paper, with the default values for the parameters.

We recruited the participants among the students of the University of Cagliari, through both board notices and social networks, asking for people already following a training programme in running (at any level). Before starting the test, each user filled a demographic questionnaire and read a description of the experiment aim and organization. We explained them that the goal of the test was to evaluate the effectiveness of two types of feedback for helping them in keeping a constant cadence during the workout.

After that, each user started with a calibration phase, where we asked them to run at a sustainable cadence. We measured the user's cadence during a workout without providing any feedback and, in order to set a target speed that would be sustainable for him/her, we took the median value of the session. The cadence was measured using the same step-counter included in the two prototypes.

For the comparison phase we used a within-subject design: each user tried both prototypes during two different workouts. In order to avoid the carryover effect, half of the users started from condition V and half of them started from condition B. In both conditions we set the same target cadence, which we obtained during the calibration.

During the workout, the application logged the current cadence, expressed in number of steps per minute. With this data we were able to calculate the difference between the target and the current cadence for each minute of the workout, whose duration was fixed to 20 minutes.

At the end of each workout condition, we requested them to rate the following aspects of the audio feedback, in a 1 to 7 Likert scale (1 strongly disagree, 7 strongly agree). We also report the question asked:

-Usefulness: Please rate how useful the audio feedback was (1 useless, 7 very useful); -Timeliness: Please rate how timely the audio feedback was (1 useless, 7 very useful); -Completeness: I had all the information I needed.

-Effort: I did not have to reason on the feedback information in order to understand what it meant. -Satisfaction: I was satisfied by the provided information.

-Precision: The provided information was precise.

In addition, we included an open-ended question for collecting suggestions and/or observations on the audio feedback.

Test Results

Twelve persons participated to the test, nine males and three females, their age ranged from 23 to 31 years old (x = 27.33, s = 2.46). Most users have an average experience with running: three of them have a training once a month, one once every two weeks, two once a week, five twice a week and one once every two days. The experience with apps for running was quite low: half of them never used them, two use it once every ten trainings, while four use apps during every session. Instead, the experience with smartphone is high for all users, all of them use apps more than once a day.

In order to evaluate the effectiveness of the two designs, we measured how good it would be to fit the recorded cadence of the user during each session with the constant value obtained from the calibration phase. In order to measure the fitting quality we used the root-mean-square error (RMSE), defined in equation 2 as the standard deviation of the difference between the target cadence c and the actual user's cadence p t at minute t (n is the duration in minutes of the workout).

RM SE = n t=1 (c -p t ) 2 n (2)
We registered a higher value of the RMSE in the vocal condition (x V = 4.84, s V = 3.79), while in the beat condition we registered both a lower central and spread values (x B = 2.33, s B = 0.50). The paired t-test highlighted a significant difference between the two means (t(11) = 2.23, p < 0.05), and the 95% confidence interval of such difference is 2.50 ± 2.48.

This shows that the beat feedback is more effective for users and that they are able to better control their cadence while running also in the case feedback is provided only when they are out of range. The users were able to synchronize their cadence with the beats even if the stimulus was not continuous during the whole exercise.

The results of the qualitative assessment are shown in figure 2. The boxplot shows that the ratings expressed for the beats version are consistently higher than those for the voice version. In particular, we found a significant difference for the usefulness (t(11) = 2.24, p < 0.05, CI = [0.02; 2.15]) and a practical significance for the precision (t(11) = 1.98. p < 0.07, CI = [-0.13; 2.48]). It is also important to notice that the timeliness of the feedback received good ratings and there is no perceived difference between the two conditions (as expected, since the Cadence Analyser had the same settings in both cases).

In the open ended questions, the users asked for more feedback when their cadence was in line with the target in both versions. Increasing the number of audio messages is obviously possible, but we should find a good balance between this need and the usage of the audio channel for e.g., listening to the music. Providing too many messages may be annoying in that case. One of the users suggested to increase the number of messages through the time, especially at the end of the training, which would be easily supported with our engine.

Considering the vocal message condition, the users highlighted in the comments some difficulties in understanding how much they should increase or decrease their speed. Once the message communicated that the cadence was not in line with the target, it was not easy for them to articulate their intention into actions. Instead, in the beats condition the user recognized that it was easy to understand how much they should change their cadence. However, they suggested to complete such information with overall information on the training (duration, kilometers covered, average cadence, etc.).

Conclusion and future work

In this paper we discussed an audio feedback engine for providing cadence information to runners while training. We discussed how we tracked the current cadence and the rules for sending audio messages, trying to balance the trade-off between the timeliness and the effectiveness of the information and the disturbance for the user. We reported the results of a user-study comparing this technique with the one currently used in different smartphone apps in the market. Finally we reported a qualitative evaluation of its overall usability.

In future work, we aim to include such feedback system into a more complex training support, where the user may set different cadences for different parts of the workout. In addition, we would like to provide the feedback system to a larger number of users, and extracting different standard default configuration profiles. In addition, we would also enhance the feedback system in order to exploit data coming from more advanced sensors that runners may own (e.g., heart-rate sensors, GPS, etc.).

Fig. 1 .

 1 Fig. 1. The Pace Analyser state machine

Fig. 2 .

 2 Fig. 2. Qualitative evaluation summary

https://www.endomondo.com/

https://www.runtastic.com/

https://secure-nikeplus.nike.com/plus/

http://www.rockmyrun.com/

http://developer.android.com/guide/topics/sensors/sensors_motion.html

http://www.rockmyrun.com/