Alessandro Caetano
email: alessandrocb@cos.ufrj.br

Leonardo Leite

Paulo Meirelles

Hilmer Neri
email: hilmer@unb.br

Fabio Kon
email: kon@ime.usp.br

Guilherme Horta Travassos

Using PageRank to reveal relevant issues to support decision-making on open source projects

Keywords: Open Source Software, Free Software, Issue Management, Decision-Making, PageRank, Empirical Software Engineering

Software release planning is crucial to software projects that adopt incremental development. Open source projects depend on their globally distributed maintainers' communities who share project information, usually described in the software project repository as issues, to plan the contents and timing of the next releases. This paper introduces an approach based on software issues to support decision-making regarding open source software development activities such as release planning and retrospectives. It uses the PageRank algorithm to suggest an importance ranking of the software issues based on the issues dependencies topology. When based on a highly connected topology, project leaders can use this rank as an input to planning activities. The observation of two open source projects indicates the feasibility of our approach.

Introduction

The developers' community is responsible for managing the next evolutionary actions in Open Source Software (OSS) projects. Such steps can identify different types of software issues, such as new features, artifacts, improvements, comments, bug fixes, among others. Collaborative Development Environments (CDE) [START_REF] Booch | Collaborative development environments[END_REF], such as GitHub and GitLab, provide essential collaboration tools, such as issue trackers, in addition to their code repositories. An issue tracker supports the community in registering new issues and discussing them, keeping track of future work as well as recording the achieved results. Although the concept of "issue" has a broader meaning than the concept of "bug" (a.k.a. software defect), in some contexts, an issue tracker can be called a "bug tracker" and its produced report, a "bug report". An issue tracker can provide essential data about the software project history and status. Data-driven decisions can contribute to the software development process improvement, helping to the timely delivery of high-quality software [START_REF] Czerwonka | CODEMINE: Building a software development data analytics platform at Microsoft[END_REF].

Researchers have conducted investigations on mining software artifacts to provide useful insights for the decision-making process on software projects [START_REF] Abdellatif | Software analytics to software practice: A systematic literature review[END_REF]. Codemine [START_REF] Czerwonka | CODEMINE: Building a software development data analytics platform at Microsoft[END_REF], for example, collects and analyzes engineering process data from across a diverse set of Microsoft product teams. Baysal et al. inquire Mozilla developers about how qualitative dashboards can support real-time developer decision-making for daily tasks [START_REF] Baysal | Developer dashboards: The need for qualitative analytics[END_REF]. Robles et al. mine commit history to estimate effort spent on a project [START_REF] Robles | Estimating development effort in free/open source software projects by mining software repositories: A case study of OpenStack[END_REF]. Borges et al. mine open source GitHub repositories to predict popularity based on repository properties [START_REF] Borges | Predicting the popularity of github repositories[END_REF]. In our work, issues are the software artifacts mined to support decision-making.

An essential input data to planning activities are the history of the project (past issues) and the set of opened issues. One could consider a set of related issues as indicating some relevant theme within an OSS community. Open issues can point to essential topics so far neglected and deserving attention. It is also possible to use information regarding closed issues to observe where a project community concentrated its efforts. Thus, looking at the history of the issues is similar to performing a retrospective study, in which the software development team can learn from the experiences and plan for future improvements [START_REF] Schwaber | The Definitive Guide to Scrum: The Rules of the Game[END_REF]. It is possible to use the retrospective based on the history of the issues to support decision-making and the prioritization of activities, and also to help identify most energy spent by the team during releases. The relevance of observing previously invested efforts is evident in the research of Robles et al., in which a model estimates the effort on the OpenStack system based on its commit history [START_REF] Robles | Estimating development effort in free/open source software projects by mining software repositories: A case study of OpenStack[END_REF].

Goyal and Sardana explore issues mining, comparing techniques for assigning the developer with maximum expertise related to a given bug to resolve it [START_REF] Goyal | Efficient bug triage in issue tracking systems[END_REF]. The match considers various meta-fields of the target bug and the meta-fields of bugs already solved by the developer. The authors also explore the effect of knowledge decay over time, a different meta-field weighting strategy, and developer commits history. Although our analysis target is the same, the bug report, our perspective is different, since we analyze the relevance of issues for the community as a whole, and not for specific developers. Some works handle the summarization of bug reports containing lengthy conversations, so the reader can quickly grasp what matters in a given bug report. He et al. focus on summarization improvement based on duplicated bug reports analysis [START_REF] He | PRST: A pagerank-based summarization technique for summarizing bug reports with duplicates[END_REF]. They apply the PageRank algorithm in a network in which nodes are the sentences of a bug report, and the similarity among them defines the edges, so the rank of sentences defines which ones belong to the summary. Although we also use PageRank to bug reports, our approach is different since we apply PageRank to reveal relevant issues from an issue set, and not to summarize a single bug report.

From another point of view, Steinmacher et al. identified 50 entry barriers faced by new developers in OSS projects [START_REF] Steinmacher | Preliminary empirical identification of barriers faced by newcomers to open source software projects[END_REF]. Among them were i) the lack of a list of project needs and issues, ii) the organization of the backlog in the repository, and iii) the access to the tasks. Thus, besides supporting planning and retrospective activities, the history of the issues is input to newcomers to know the project better and decide where to focus efforts.

A well-organized project may have hundreds or even thousands of issues. Considering such significant set of issues is hard for decision-making, one should analyze every single software issue to produce consistent high-level patterns. For this reason, OSS communities could benefit from automated approaches to extract relevant information from the issue tracker to support decision-making activities.

In the issue tracker facilities provided by the GitHub and GitLab, users can reference an issue from comments or titles on other software issues, creating a network of linked issues (see Section 2). Considering such issues network, we propose in this paper an approach to define the top-ranked software issues from a given repository, by using the PageRank algorithm [START_REF] Page | The PageRank citation ranking: Bringing order to the web[END_REF] to determine the relevance of issues based on their network centrality. Issues with a large number of references (dependencies) are more likely to be highly relevant, and consequently, those referenced by relevant issues are more likely to be also highly relevant. This way, the outcome of the PageRank algorithm (a list of software issues ordered by relevance) can support retrospective studies, planning activities, and look for relevant opportunities for newcomers to work out. Therefore, this paper intends to answer the following research question: Can the PageRank algorithm identify relevant issues on OSS projects to support decision-making?

We used two observational studies with two OSS projects to support the answering of this question. The observed results indicate that the use of PageRank could be somewhat feasible since some ranked relevant issues presented terms aligned to the planning documentation, and others were related to effortconsuming activities.

We organized the remaining of this paper as follows. Section 2 describes some basic concepts on the model of software issues and the PageRank algorithm. Section 3 presents our proposal to determine the relevance order of software issues according to the PageRank algorithm. In Section 4 we discuss the evaluation of our approach. Section 5 presents some threats to the validity of this study. Finally, Section 6 draws our conclusions and future work.

Background

In this section, we present how to build a graph representation of software issues extracted from Github and Gitlab platforms. We also discuss the PageRank, a link analysis algorithm that we applied to find the top-ranked software project issues.

The software issue model

Software issues are used in CDEs such as GitHub and GitLab to organize community activities. Software issues can have many purposes, such as discussing new ideas, asking for help, registering desired new features, artifacts improvements, fixes and so forth.

Each software issue has a number, a title, a textual description, and commentaries by its contributors. An issue title or commentary may refer to another software issue through a short link by using the "#" sign followed by the issue number. Commit messages can also refer to software issues in this style.

A software issue starts in the "open" state and finishes in the "closed" state. An issue is closed when it is addressed, rejected, or incorporated by another software issue. It may be assigned to a specific member of the software community and linked to a milestone. In this context, a milestone is a cohesive collection of software issues, possibly associated with a due date. A milestone, therefore, represents a project goal in a higher level of abstraction than just one issue.

The PageRank algorithm

Larry Page and Sergey Brin created the PageRank algorithm in 1999 [START_REF] Page | The PageRank citation ranking: Bringing order to the web[END_REF]. It calculates the relative importance of web pages, and it has applications in search engines, traffic estimates, and web browsing. The premise of the PageRank algorithm is that each web page has some outbound and inbound links and that pages with a large number of links are more relevant than pages with fewer links. Besides, the algorithm takes into account the relevance of incoming links to a page: if the web page has an inbound link that has high relevance, that page tends to be more important than another one having several links coming from less relevant pages. The equation used to calculate the rank in the PageRank algorithm is:

P R(x) = α 1 N + (1 -α) y∈L(x) P R(y) C(y) , (1)
in which x a web page, P R(x) is the page rank of x. L(x) represents the pages with links to x, C(y) is the out-degree of y, α represents the probability of a random jump from one of the links, that is, in a random-surfer model it represents the probability of the surfer restart the algorithm at any given page, preventing the algorithm to be stuck in a node with zero out-degree. N represents the total number of pages analyzed.

3 Using PageRank to reveal relevant software issues Our approach to analyzing the relevance of issues consists in using the PageRank algorithm, i.e., applying Equation 1 to software issues rather than to web pages. So, the first step of our procedure is generating a directed graph based on data retrieved from the software repository. We retrieve such data using the APIs provided by GitHub and GitLab. In the generated graph, a vertex represents a software issue, and a directed edge represents a link from a software issue to another one, only issues linked using the "#" sign are considered.

Before applying the PageRank algorithm, two transformations are performed in the graph. The first is to connect all software issues within the same milestone. We consider this connection because software issues within the same milestone have a semantic bind that means that all of them must be fulfilled so that a higher-level objective is achieved. The second transformation eliminates software issues with no links. A software issue is kept whether it has at least one inbound link or one outbound link. This transformation is made because software issues with no links are irrelevant to the analysis and affect the rank scale, so pruning these software issues generates a result that is easier to interpret.

After the graph is prepared, Equation 1 is applied to the graph with α = 0.85, which is the default value used in NetworkX [START_REF] Hagberg | Exploring network structure, dynamics, and function using NetworkX[END_REF], a library for network manipulation we used, and the recommended value from the original Pagerank proposition [START_REF] Brin | Reprint of: The anatomy of a large-scale hypertextual web search engine[END_REF]. The result is the assignment of a real number called "rank" to each software issue and a list of software issues ordered from the highest to the lowest rank.

Our implementation source code (including data retrieving, graph preparation, and PageRank execution) is available at GitLab5 . We built the automated solution in Python. The top-ranked libraries we used are Matplotlib for data visualization [START_REF] Hunter | Matplotlib: A 2D graphics environment[END_REF]; Scipy6 for numerical computing; Pandas7 for data frame manipulation; NetworkX [START_REF] Hagberg | Exploring network structure, dynamics, and function using NetworkX[END_REF] to generate a digraph and compute the PageRank; and NLTK8 to find the patterns we were looking for in the issue text.

Evaluation

We automated an approach to be used by any project that adopts the GitHub or GitLab issue trackers to organize the software community activities. We evaluated it by observing two OSS projects: Brazilian Public Software portal 9 , with its project repository in its own GitLab instance, and Parliamentary Radar10 , which uses Github.com to host its project repositories. We choose these Brazilian software projects because they documented their roadmaps and backlogs, which enabled us to use this documentation to evaluate the algorithm results. Moreover, the proximity of our research group to the developers of these two software projects helped us to perform qualitative assessments regarding our findings with the project members.

The Brazilian Public Software (SPB) portal is an integrated platform for collaborative software development of OSS projects used by the Brazilian public administration [START_REF] Meirelles | Brazilian Public Software Portal: An integrated platform for collaborative development[END_REF]. It includes facilities for social networking, mailing lists, version control, and monitoring of source code quality, making it a system-of-systems.

The Parliamentary Radar project uses open government data to perform cluster analysis on bill votes of legislative houses of Brazil.

The input to PageRank algorithm is the software issues graph. Figures 1 and2 present the generation of the software issues graphs, which is the first step of our approach, for the SPB Portal and Parliamentary Radar projects. In these figures, the tiny red circles (altogether forming an ellipse) represent the software issues, whereas the straight lines represent links between them. In short, the graphs use a circular layout, as proposed by Dogrusöz et al. [START_REF] Dogrusöz | Circular layout in the Graph Layout toolkit[END_REF]. The SPB graph already contains the transformations to linking the issues of the same milestone and pruning those with no links. The Radar Parliamentary graph includes the transformation of pruning software issues with no links. However, since the Parliamentary Radar project does not systematically use milestones, we did not perform the linkage of software issues of the same milestones to it.

For the SPB portal project, the removal of issues with no links decreased from 800 to 127 the number of software issues in the graph. After the cut, about 62.5% of them have only one link. Some issues appear with two and three links, and there are also three issues with four, five and six links each. Using the issues graph of Figure 1, we performed the PageRank algorithm. Table 1 shows the top ten ranked issues. The removal of Parliamentary Radar project issues with no links decreased from 300 to 71 the number of software issues in the graph. After the cut, about 50% of them had just one link. Some issues appear with two, three and four links, and there is one issue with eleven links. Using the issues graph of Figure 2, we performed the PageRank algorithm. Table 2 shows the top-ranked issues.

The rank values of SPB project issues varied from 0.002 to 0.0172. The median is 0.0028 and the mean 0.0040 with a standard deviation of 0.0018. About half of the issues presented the same rank of 0.002. The histogram in Figure 3 represents the distribution of the generated ranking. For the Parlia-mentary Radar project issues, the ranks values varied in a range from 0.0046 to 0.0124. The median is 0.0059 and the mean 0.0063 with a standard deviation of 0.0020. Figure 4 presents the histogram plot for the Parliamentary Radar. We compared the top-ranked software issues of the SPB portal project to the planning of the two last releases documented on the SPB wiki. We performed the comparison looking for the terms present in issue titles, descriptions, and wiki pages. In the SPB releases documentation, some priority features were "software usage report", "global search improvement", and "general improvements". These terms align with terms found in the top-ranked software issues. We also conducted an open interview with the SPB Portal coordinator presenting the ranked list of issues to him, who provided feedback that the ranked list showed the issues that consumed the most effort from the team at the project end. It suggests the feasibility of our approach in capturing some of the relevant issues from the management point of view.

The Parliamentary Radar project maintains its roadmap and backlog organized in the Wiki at its repository. Its backlog11 describes features desired for the project. A set of software issues may represent different tasks to implement a feature. We compare the ranked list of software issues of Parliamentary Radar project and its roadmap to evaluate the result of our PageRank execution. In this way, it was possible to align the top-ranked issues with the features presented in the backlog to indicate if the proposed approach to determining the software issue relevance gives satisfactory results.

When comparing the Parliamentary Radar ranked software issues list with the project backlog, we observed that our solution identified software issues that were prioritized by developers. With this, we also conducted an open interview with three core developers of Parliamentary Radar and presented the ranked list of issues to them. We got the feedback that the highly relevant issues list presented the three issues that consumed the most effort from the team at that moment, which indicates that our approach was able to identify highly relevant software issues from the developer point of view.

Moreover, the Parliamentary Radar developers stated that if they had this suggestion when planning the next release, they could have prioritized other software issues included in the list instead of some that they preferred to prioritize. They also stated that the list of ranked software issues could also be useful during the team retrospective since it can help developers to identify the most discussed ones. The Parliamentary Radar developers also proposed that newcomers can use the list of ranked software issues to have an insight on what the software community is working on, creating a better way for their engagement in the software under development.

Threats to Validity

An internal validity threat occurs because the Parliamentary Radar roadmap had not been updated at the time we executed our scripts. So, the roadmap could not be related to software issues created after the last wiki update. However, the Parliamentary Radar wiki content had enough information to correlate software issues terms and planning documentation. Moreover, in the SPB Portal project, the wiki content was more reliable, so the sound results for both projects support the applicability of such comparison.

About external validity, we acknowledge that executing our approach with only two OSS projects imposes barriers to a broader generalization regarding our approach applicability. However, at least the positive observations of these two projects are encouraging and can motivate other communities to try out our proposal. Our approach is limited by how the developers organize the issue tracker of their projects. Since the algorithm depends on the links of the issues, it requires a cultural practice for the community to create these links.

In the evaluation process, the main reproducibility problem is the manual comparison made between terms found on top-ranked software issues and terms present in the planning documentation. An automated process for such comparison would be more suitable. On the other hand, the planning documentation for both SPB Portal and Parliamentary Radar projects are relatively small, so we hope someone trying to reproduce our study might get very similar results.

Conclusion

We presented the application of the PageRank algorithm to a network of software issues retrieved from OSS projects. Its use results in a ranking of issues, which can support a software community in decision-making activities, such as the planning of releases, retrospective studies, and helping newcomers to know the project better.

The presented results showed the feasibility of our approach for the Brazilian Public Software portal and Parliamentary Radar projects because some of the top-ranked software issues were also present in their planning documentation.

Furthermore, in open interviews with the coordinators and the core developers of the projects, they found the software issues rank insightful in both management and development views. Therefore, we consider that the PageRank algorithm may be used to extract a small set of relevant issues from OSS repositories to support decision-making activities regarding retrospective studies, to support new developers to engage on activities that are currently being worked by the software community, and to track the effort of the team. However, before generalizing its use for all OSS projects, it is vital to understand peculiarities of the software community and project that could affect the results.

Answering the question "Can the PageRank algorithm identify relevant issues on OSS projects to support decision-making activities?", the obtained results indicate that our approach can adequately work for those software projects using the Github or Gitlab software issue trackers and in which the contributors create a substantial number of links among issues. The issues should represent activities for the developers, the links between them should represent the relations between two or more activities, that way the algorithm can rank the issues helping the developers prioritize them. Given OSS projects following the specific structures presented in this study, we can answer our research question positively, since the algorithm was able to reveal a set of relevant issues regarding both the software projects. However, since we applied our approach to two OSS projects, more studies are necessary to strengthen this claim.

The adoption of our approach by OSS communities requires a way to integrate the execution and the presentation of results without the need to manually run scripts. To facilitate more studies based on our approach, we shared a package with the scripts used in this study on Gitlab, as described in Section 3. Future studies can evaluate the impact of our graph transformations, i.e., linking software issues within the same milestone and pruning those with no links. Finally, structured interviews with adopters of the approach would allow a better evaluation triangulation and broaden its applicability assessment for an extensive range of OSS projects.

Fig. 1 .

 1 Fig. 1. Software issues circular graph of the SPB Portal project.

Fig. 2 .

 2 Fig. 2. Software issues circular graph of the Parliamentary Radar project.

Fig. 3 .

 3 Fig. 3. Histogram of ranks for the SPB Portal issues.

Fig. 4 .

 4 Fig. 4. Histogram of ranks for the Parliamentary Radar issues.

Table 1 .

 1 The top ten ranked issues of the SPB Portal.

	Issue

Table 2 .

 2 The top ten ranked issues of the Radar Parlamentar.

	Issue

https://gitlab.com/AlessandroCaetano/PageRanking

https://scipy.org

http://pandas.pydata.org

http://nltk.org

https://softwarepublico.gov.br

http://radarparlamentar.polignu.org

https://github.com/radar-parlamentar/radar/wiki/Roadmap


Remo Eckert
email: remo.eckert@iwi.unibe.ch

How can Open Source Software Projects be compared with Organizations?

Keywords: Open Source Software, OSS Governance, OSS Framework

The existence of a community plays a central role in the development of Open Source Software (OSS). Communities are commonly defined as a group of people sharing common norms or values. The common interest of an OSS project is obvious: to develop software under an OSS license. When we look at the rather general definition of a community, we see that there is a similarity to the term 'organization'. This paper draws parallels between OSS projects and the general elements of an organization and shows the different elements comprised in an OSS community: people, organization and assets. Each of those elements is enriched with examples from different research in the corresponding OSS research stream and provides a broad overview of the elements of OSS projects. With the help of this comparison, research on OSS can be made more focused and aligned with organizational research.

Introduction

The phenomenon of OSS has attained much attention over the years. In the academic literature, different aspects of OSS and its development have been examined and discussed. Quite often, however, the terms used to describe the different phenomena around OSS are not exactly defined and even more the relationship between different concepts is not clarified. For example, OSS research often uses various different concepts of a collective that works together to reach a common goal, such like community, project, organization, or foundation. This results in a situation where it is not always clear what is exactly meant with the concepts, what do they comprise and how they relate to each other. The development of OSS takes place in an OSS project. By creating a three-phase model, de Laat [START_REF] De Laat | Governance of open source software: state of the art[END_REF] describes the structural evolution of an OSS project. In phase one, governance is spontaneous and explicit coordination and control are non-existent. Phase two introduces internal governance with formal tools, e.g. division of roles, training, modularization or decision-making. This enables an OSS project to be governed internally in order to increase efficiency and effectiveness as the community grows. Eventually, in phase three, if the OSS project is successful and both companies and other organizations wish to participate, there is a need for institutionalization (a legal entity such as a foundation) to involve outside parties such as organizations [START_REF] De Laat | Governance of open source software: state of the art[END_REF].

Governance within OSS projects has been widely discussed for many years [START_REF] De Noni | The evolution of OSS governance: a dimensional comparative analysis[END_REF][START_REF] Franck | Reconciling rent-seekers and donators-The governance structure of open source[END_REF][START_REF] Schaarschmidt | How do firms influence open source software communities? A framework and empirical analysis of different governance modes[END_REF]. One frequently used definition of OSS governance is "the means of achieving the direction, control, and coordination of wholly or partially autonomous individuals and organizations on behalf of an OSS development project to which they jointly contribute" [START_REF] Markus | The governance of free/open source software projects: monolithic, multidimensional, or configurational?[END_REF]. In order to better understand what governance of an OSS project is, one needs first to understand the different elements of what is to be governed. However, there is no research that attempts to explain those different elements of an OSS project. Thus, there is a need for studies that contribute to a better understanding of the different elements comprised within an OSS project. Therefore, this paper attempts to answer the following question: What are the different elements comprised within an OSS project? To answer our research question, we have developed a framework in which OSS projects are compared to the elements of an organization.

The remainder of this paper is structured as follows: Chapter 2 shows the elements of an organization because we perceive an OSS project as an organization in the most generic sense. Chapter 3 adapts these elements to OSS projects and explains the different elements of an OSS project. Chapter 4 discusses the results and the implications thereof for both theory and practice.

The Elements of an Organization

An organization is defined as an entity comprising multiple actors with a collective goal [START_REF] Luhmann | Funktionen und Folgen formaler Organisation[END_REF]. According to organizational research, governance combines various mechanisms to encourage people to do things that align with the organization's goals [START_REF] Choudhury | Portfolios of Control in Outsourced Software Development Projects[END_REF]. According to Luhmann [START_REF] Luhmann | Funktionen und Folgen formaler Organisation[END_REF], there are three characteristics that highlight the organization: first, an organization can decide which people are part of it and which are not. The organization can define restrictions and rules; failure to observe these rules can result in exclusion. Second, organizations have goals and the decisions an organization takes are oriented around these goals. Generally, organizations have several processes, which can be structured either in management processes, in core processes or in supporting processes. Core processes are central for an organization to earn money, whereas management processes structure an organization to achieve those core processes. Supporting processes are necessary to run the core processes, but are not central to an organization [START_REF] Becker | The Process in Focus[END_REF]. Third, organizations have hierarchies, which regulate the position of members within the organization. Processes and hierarchies enable an organization to coordinate its people. Processes and hierarchies, both formal and informal, therefore represent mechanisms of governance to align the behavior of people according to organizational goals [START_REF] Choudhury | Portfolios of Control in Outsourced Software Development Projects[END_REF].

Besides people, common goals, roles, rules and structures, most -if not all -organizations are in need of assets. Assets are tangible or intangible goods and can be owned or controlled to produce and have a positive economic value. Moreover, they can be converted into cash [START_REF] O'sullivan | Economics: Principles in Action[END_REF]. From an accounting viewpoint, an asset is a resource controlled by an entity as a result of past events and from which future economic benefits are expected to flow to the entity. An asset can be tangible or intangible [START_REF]IFRS Foundation: International Financial Reporting Standards[END_REF].

The establishment of a legal entity helps to protect an organization from various threats such as liability. Fig. 1 combines Luhmann [START_REF] Luhmann | Funktionen und Folgen formaler Organisation[END_REF] and the accounting viewpoint and shows the different elements of an organization. Although Fig. 1 implies a welldefined structure, each element is closely interlinked with the other elements.

Organizational Framework of OSS Projects

In the following subsections, we explain how each of the corresponding elements of people, organization and assets can be understood in regards to OSS projects. The following subsections show that the similarities between an organization and OSS can be structured according to our organizational framework.

People

OSS projects are associations consisting of people who come together virtually in pursuit of a common goal [START_REF] Rheingold | The Virtual Community: Homesteading on the Electronic Frontier[END_REF]. The motivation to contribute to an OSS project differs: contributors to an OSS project can either be paid by an employer, or are volunteers. In general, their reasons for contributing to OSS projects can be categorized as either intrinsic or extrinsic motivation [START_REF] Von Krogh | Carrots and rainbows: Motivation and social practice in open source software development[END_REF]. An action is extrinsically motivated when it is performed in order to obtain some separable outcome, whereas an intrinsically motivated action is carried out for the mere interest in or joy of performing it [START_REF] Deci | The general causality orientations scale: Self-determination in personality[END_REF]. However, the motivations behind employees and volunteers contributing to an OSS projects differ [START_REF] Roberson | Understanding the motivational effects of procedural and informational justice in feedback processes[END_REF]. A developer's "itch worth scratching", as stated by Raymond, might be not as strong for a paid developer as for a volunteer [START_REF] Raymond | The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary[END_REF]. Tasks such as project design, coordination, testing, documentation and bug-fixing are usually less attractive for volunteers and could therefore be carried out by hired people to ensure that these tasks will be done properly [START_REF] German | The GNOME project: a case study of open source, global software development[END_REF]. We therefore distinguish between hired people and volunteers.

Volunteers. The involvement of a community in an OSS project is a vital factor for the success of the project because the community promotes the project and its development [START_REF] Bagozzi | Open Source Software User Communities: A Study of Participation in Linux User Groups[END_REF][START_REF] Iivari | Empowering the users? A critical textual analysis of the role of users in open source software development[END_REF]. Therefore, attracting and gaining volunteers for a new OSS-project is one of the main focus of community building. The community can ease the way in which new volunteers can join the community by defining guidelines, compiling mailing lists and wikis and answering project-related questions [START_REF] Von Krogh | Community, joining, and specialization in open source software innovation: a case study[END_REF]. Moreover, the software quality itself may increase the success rate of attracting new members, whereas several methods of enhancing the quality of the code exist, ranging from code refactoring to documentation [START_REF] Kilamo | From proprietary to open source-Growing an open source ecosystem[END_REF]. On the technical side, increasing modularity of the source code is one incentive for attracting new developers [START_REF] Maccormack | Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code[END_REF]. Another way to attract more volunteers to an OSS project is to use an issue tracking system [START_REF] Heppler | Who Cares About My Feature Request?[END_REF]. OSS projects typically have an open issue tracker where developers and users of the software can report bugs and feature requests [START_REF] Anvik | Who Should Fix This Bug?[END_REF]. With the help of issue trackers, potential new contributors can get in touch with the existing community. In their literature review, von Krogh et al. [START_REF] Von Krogh | Carrots and rainbows: Motivation and social practice in open source software development[END_REF] distinguish between intrinsic, internalized extrinsic or extrinsic motivations. As stated by von Krogh et al. [START_REF] Von Krogh | Carrots and rainbows: Motivation and social practice in open source software development[END_REF], some motivations are by definition extrinsic, but could be internalized by developers so that they are perceived as self-regulating behavior rather than external impositions. Hired Contributors. A high number of developers are paid by an employer for their OSS efforts [START_REF] Hars | Working for free? Motivations of participating in open source projects[END_REF]. In a study by O'Mahony and Bechky [START_REF] O'mahony | Boundary organizations: Enabling collaboration among unexpected allies[END_REF], 63% of respondents were paid by a corporate sponsor. In the GNOME project, tasks which are usually less attractive to volunteers, such as project design and coordination, testing, documentation and bug-fixing are carried out by employees [START_REF] German | The GNOME project: a case study of open source, global software development[END_REF]. People who are paid to contribute to an OSS project may be paid directly by an organization which benefits from the developed software. For example, Red Hat will make more money on support if Linux is used more. Another example is Intel. It will sell more semiconductors if an operating system is free, and a computer therefore costs less. As a result, such companies hope to benefit from allocating their own employees to an OSS project [START_REF] Bonaccorsi | Comparing motivations of individual programmers and firms to take part in the open source movement: From community to business[END_REF][START_REF] Lerner | Some Simple Economics of Open Source[END_REF]. Berdou [START_REF] Berdou | Insiders and outsiders: paid contributors and the dynamics of cooperation in community led F/OS projects[END_REF] distinguishes between free sponsorship, clear mandate, OSS-friendly jobs and sub-contracting. In free sponsorship, developers receive no clear instruction from their employer about what they should work on. For the most part, they are former volunteers, who are expected to work on more or less the same things they used to. In contrast to free sponsorship, those who have a clear mandate from their employer, are told what they ought to work on, such as integrating different aspects of the project into company products, or building on their projects' platform to create commercial applications. OSS-friendly jobs are jobs where people are expected to develop proprietary software, but are also allowed to spend part of their time working on OSS projects. Their terms of work can be formal or informal and resemble part-time free sponsorship. In subcontracting, meanwhile, people are paid to solve a problem or develop a specific application. This form could also include bounty programs (cash reward offered for development) and self-employed developers. However, people can also be paid by an OSS foundation, as it is in the GNOME Foundation, where the executive director and an administrator, as well as other contractors, are paid via membership fees to accelerate community growth and sustainability [START_REF]GNOME Foundation -Fiscal Year 2016 Annual Report[END_REF].

Organization

Some OSS projects, especially bigger ones, have formal membership rules and agreements, such as the membership fee and bylaws with different roles and functions [START_REF] Von Krogh | Community, joining, and specialization in open source software innovation: a case study[END_REF]. Bylaws are rules established by the community to regulate itself in a structural and in a procedural way. As an example, the bylaws of the Eclipse Foundation regulate the overall purpose of the community, the powers and duties of the various roles within the community, how and when members are elected and how meetings are organized. Moreover, the Eclipse Foundation bylaws explain how decisions are made, explain the tasks of the different committees, councils, boards and the different forms of membership [START_REF]The Eclipse Foundation: Bylaws of Eclipse Foundation, Inc[END_REF]. Contributions not only help the software to evolve, but also redefine the role of the contributors, thereby changing the social dynamics of the community. Consequently, project leaders and core members should focus not only on the evolution of the software itself, but also on the creation of an environment and culture that fosters and encourage new members to move toward the center of the OSS community. This can happen by means of both formal and informal mechanisms. Such mechanisms allow developers to work independently, by encouraging or helping other developers to work in ways that are expected by the community [START_REF] Jensen | Collaboration, leadership, control, and conflict negotiation and the netbeans.org open source software development community[END_REF].

Structures. Relationships with external groups, leadership and control are common sources of conflict in an OSS project. In the worst case, these can even lead to a breakdown or a software fork where a subgroup of contributors develop their own version of the code [START_REF] Gamalielsson | Sustainability of Open Source software communities beyond a fork: How and why has the LibreOffice project evolved[END_REF][START_REF] West | Contrasting community building in sponsored and community founded open source projects[END_REF]. A structure regulates the coordination efforts between different actors. Although there is no strict hierarchy in some OSS communities, their structure is not completely flat. According to [START_REF] Nakakoji | Evolution patterns of open-source software systems and communities[END_REF], roles and their associated influence can be earned through contributions to the community. The resulting informal community structure, called the "onion-model" can be depicted as layers, where the roles closer to the center (e.g. the project leader and core members) have a greater influence than the roles in the outer layers (e.g. readers and passive users). The roles are not fixed and can change over time, depending on the contributions of the community members involved. The processes are in many cases more informal than formal, anyone can join and the relations and roles change over time [START_REF] Dahlander | Relationships between open source software companies and communities: Observations from Nordic firms[END_REF]. Roles do not imply authority, but instead responsibility. Authority, as an example in the NetBeans community, is based on reputation and respect [START_REF] Jensen | Collaboration, leadership, control, and conflict negotiation and the netbeans.org open source software development community[END_REF].

O'Mahony and Ferraro [START_REF] O'mahony | The emergence of governance in an open source community[END_REF] show how a community uses a formal bureaucratic basis of authority to reinforce its meritocratic norms. They show how an OSS project designed a governance system that combines a constitutional basis of authority with democratic mechanisms to ensure control by the majority. A governance system shapes the way in which project-wide decisions are made. Moreover, governance structures ensure that a project could survive a change in leadership or crucial positions within the project. The need to coordinate member activities and integrate their contributions necessitates a structure. Analyzing the Debian project, O'Mahony and Ferraro [START_REF] O'mahony | The emergence of governance in an open source community[END_REF] distinguish between four different forms of governance, where the community develops from an informal to a formal structure. In the Debian project, the de facto governance worked well for the first five years. There were no formal means of governance. In the designing governance phase, a formal definition of roles, rights and responsibilities was established. The resulting governance system embraced two elements -the formal positional authority and the limitation of that authority through democratic means. In phase three, implementing governance, the new formal governance structure accepted by the community, was implemented. Candidates nominated themselves and the community could give them their vote. In phase four, stabilizing governance, the leadership forms began to reach settlement.

Processes. Like an organization, an OSS project also has various processes, which can be structured in core processes, management processes and support processes.

Core processes. While many OSS projects are built by a small number of individuals, in large projects, a significant number of individuals and firms contribute to the project [START_REF] Markus | The governance of free/open source software projects: monolithic, multidimensional, or configurational?[END_REF][START_REF] Lerner | Some Simple Economics of Open Source[END_REF][START_REF] Scacchi | Understanding the requirements for developing open source software systems[END_REF]. Formal rules about the development process ensure that operational tasks, such as requirements elicitation, assignment of people to tasks, release control, etc. are organized [START_REF] Markus | The governance of free/open source software projects: monolithic, multidimensional, or configurational?[END_REF]. The Eclipse development process, for example, describes the principles upon which the process should rely: openness, transparency and meritocracy. Moreover, each project is supposed to make a project plan available to the community at the beginning of each development cycle (for each major and minor release) [START_REF]The Eclipse Foundation: Eclipse Development Process[END_REF]. Another core process is requirements engineering. German [START_REF] German | The GNOME project: a case study of open source, global software development[END_REF] illustrates how several leaders in the GNOME project provide a list of requirements that the system should satisfy and reference applications the project should replace. However, not all requirements are an output of the leaders. Requirements for a new module or components are born from discussions in mailing lists or on an issue tracker [START_REF] Heppler | Who Cares About My Feature Request?[END_REF]. Requirements can be formulated in a vision developed by community leaders; by imitating the features from reference applications; by discussions in a mailing list; by providing a prototype with the implemented requirements to work on; or by a post-hoc requirement where the requirements are unknown to the rest of the community and are fulfilled by the developer seeking those requirements. What those methods have in common is that they are usually informal and prioritized by the leaders of the project, maintainers of the module or by a foundation [START_REF] Scacchi | Understanding the requirements for developing open source software systems[END_REF].

Management processes. OSS projects, especially larger ones, exhibit formal structures that can be described in bylaws. German [START_REF] German | The GNOME project: a case study of open source, global software development[END_REF] describes how the board of directors in the GNOME community is elected. The board of directors is democratically elected by the rest of the foundation members. In addition, the community has a rule that restricts the power of a single organization by imposing a maximum number of board seats. Moreover, board members must represent the interests of the GNOME community, not the interests of their own organization. This rule, as stated, has already been enforced several times in the past.

Supporting processes. The developed software asset needs to be protected from lawsuits from the legal entity that owns it [START_REF] O'mahony | Guarding the commons: how community managed software projects protect their work[END_REF]. Therefore, the OSS community needs to ensure that contributions do not infringe third-party IP-rights. For example, a contributor agreement ensures that the OSS community cannot be subject to a firm's ownership claim and is therefore seen in some OSS projects as a precondition to any code contribution [START_REF] O'mahony | Boundary organizations: Enabling collaboration among unexpected allies[END_REF]. Another example of a supporting process is the funding process. Since there are different forms of memberships and fees, the Eclipse Bylaws define which people have to pay for becoming a member and how much [START_REF]The Eclipse Foundation: Bylaws of Eclipse Foundation, Inc[END_REF]. The secretary is responsible for invoicing membership fees and collecting fees, if necessary with a dues notice. The annual report, which is publicly available, provides an overview of the financial situation of the Eclipse community in terms of revenues and expenses. This report, which encompasses far more than just the financial situation, also constitutes a supporting process.

Assets

We distinguish between tangible and intangible assets, which are described in detail in the following. Tangible Assets. With respect to the development of software, the availability of an IT Infrastructure is an important aspect. Gutwin et al. [START_REF] Gutwin | Group awareness in distributed software development[END_REF] found that distributed developers do need to maintain awareness of one another, more specifically, both a general awareness of the entire team and more detailed knowledge of the individuals they plan to work with. The main mechanisms for maintaining this awareness of who is involved in the project and what their activities are, are text-based communication tools that are commonly used in OSS project, e.g. mailing lists, wikis or text chats. For specific awareness, such as people's expertise and activities, an operating IT Infrastructure with a decentralized version control system such as GIT [START_REF] Kalliamvakou | Open source-style collaborative development practices in commercial projects using github[END_REF], bug trackers for submitting bugs and feature requests, e.g. Bugzilla [START_REF] Heppler | Who Cares About My Feature Request?[END_REF] and mailing lists [START_REF] Markus | The governance of free/open source software projects: monolithic, multidimensional, or configurational?[END_REF][START_REF] O'mahony | The emergence of governance in an open source community[END_REF] are needed. Collaboration among the participating members takes place with the help of these tools and simplifies the effort required for distributed software development [START_REF] German | The GNOME project: a case study of open source, global software development[END_REF]. As recommended by German [START_REF] German | The GNOME project: a case study of open source, global software development[END_REF], communication should be carried out via a variety of tools. All such tools, including the servers they run on, represent IT Infrastructure [START_REF] German | The GNOME project: a case study of open source, global software development[END_REF][START_REF] Ducheneaut | Socialization in an Open Source Software Community: A Socio-Technical Analysis[END_REF].

If an OSS project wants to obtain contributions, it needs to market itself. This includes hosting a website with the published source code of the OSS project. Therefore, a webserver is required. As an example, a committer must have access to the latest code base in order to insert changes into that base [START_REF] Jørgensen | Putting it all in the trunk: Incremental software development in the FreeBSD open source project[END_REF]. Normally, this is done using a decentralized version control system (DVCS) such as GIT, which facilitates collaboration among various developers [START_REF] Kalliamvakou | Open source-style collaborative development practices in commercial projects using github[END_REF]. However, a DVCS and a website need to run on a server with guaranteed Internet access. As described by German [START_REF] German | The GNOME project: a case study of open source, global software development[END_REF], at the level of community IT Infrastructure, servers as well as bandwidth are required to communicate and share collaborators' progress. As an example, the GNOME community relies upon donations from the Autonomous University of Mexico and other organizations that provide its IT Infrastructure [START_REF] German | The GNOME project: a case study of open source, global software development[END_REF].

Because the majority of work in an OSS project is performed by globally distributed individuals, face-to-face meetings are rather rare. However, they help to better communicate and resolve potential conflicts [START_REF] Gutwin | Group awareness in distributed software development[END_REF]. Consequently, infrastructure in the form of rooms for meetings and an internet connection can help to reduce potential communication problems. Moreover, if the OSS project has a legal entity, its address can be used for corresponding purposes.

Intangible Assets. Although OSS does not fully meet the conditions to be included as an asset in financial reports [START_REF] García-García | Valuation of Open Source Software: How do you put a Value on free?[END_REF], it can be protected in different ways, such as intellectual property rights (IPR), trademarks and brands. As stated by Fitzgerald [START_REF] Fitzgerald | The transformation of open source software[END_REF], trademarks or brands are alternative mechanisms to protect IPR in addition to the license itself. A trademark can protect the OSS project's reputation by preventing other projects using their name or brand (e.g. a software fork with other goals than the main project). The goal of a trademark is to prevent customers from confusion as to the origins of the product or service [START_REF] Anderson | Passport Without A Visa: Open Source Software Licensing and Trademarks[END_REF]. A common practice among OSS foundations is to own the copyright of the source code and related texts, as stated by Riehle [START_REF] Riehle | The Economic Case for Open Source Foundations[END_REF].

However, a legal basis for a growing community, especially when firms are involved, is necessary. Firms are reluctant to donate code to a project without transferring responsibility for it. Without a legal owner, firms hesitate to donate code and transfer responsibility for future maintenance. The establishment of a foundation offers firms a legal entity to which ownership can be transferred [START_REF] German | The GNOME project: a case study of open source, global software development[END_REF][START_REF] O'mahony | Boundary organizations: Enabling collaboration among unexpected allies[END_REF]. IPR are better defined and more defensible when owned by a single legal entity as opposed to various individuals.

Having a single and central copyright holder means that it holds the asset and therefore can protect it more easily compared to the situation when hundreds of contributors hold the individual rights to their parts. Furthermore, a legal entity ensures that volunteer contributors are protected against individual liability, and can enter into agreements collectively and protect their code, trademarks, licenses and brands on their behalf [START_REF] O'mahony | Guarding the commons: how community managed software projects protect their work[END_REF].

Discussion

Our organizational framework compares OSS projects with the typical elements of an organization by showing the different elements exhibited by an OSS project and comparing these with the elements of an organization. According to our framework, the three main elements of an OSS project are people, organization and assets. Each of those elements is enriched with examples from different research in the corresponding OSS research stream and provides a broad overview of the elements of OSS projects. The people dimension refers to the concept of a community. Contributors to an OSS project therefore can either be hired or volunteers. OSS projects are associations consisting of people who come together virtually in pursuit of a common goal [START_REF] Rheingold | The Virtual Community: Homesteading on the Electronic Frontier[END_REF]. Tasks such as the project design, coordination, testing, documentation and bug-fixing are less attractive for volunteers and could therefore be carried out hired staff to ensure that these tasks are done [START_REF] German | The GNOME project: a case study of open source, global software development[END_REF]. Due to the fact that, in some OSS projects, more than half of the contributors are paid by a corporate sponsor [START_REF] O'mahony | Boundary organizations: Enabling collaboration among unexpected allies[END_REF], we see that OSS governance is becoming increasingly important. A key aspect of OSS governance is therefore managing the community [START_REF] Markus | The governance of free/open source software projects: monolithic, multidimensional, or configurational?[END_REF].

What we call the organizational dimension as well as the asset dimension, can be compared to the concept of governance. Similar to Markus [START_REF] Markus | The governance of free/open source software projects: monolithic, multidimensional, or configurational?[END_REF], we see formal and informal structures and norms as one of the main elements of OSS governance. Different projects have a varying degree of formalism, with some lacking any formal descriptions at all on how decisions are made. However, there are a number of OSS projects with formal rules and agreements, such the bylaws, with different roles and functions [START_REF] Von Krogh | Community, joining, and specialization in open source software innovation: a case study[END_REF]. When firms participate in an OSS project, the degree of formalism may increase [START_REF] O'mahony | Boundary organizations: Enabling collaboration among unexpected allies[END_REF]. Similar to Markus [START_REF] Markus | The governance of free/open source software projects: monolithic, multidimensional, or configurational?[END_REF], we see ownership of assets as one of the main areas of OSS governance. Although OSS does not fully meet the conditions to be included in financial reports as an asset [START_REF] García-García | Valuation of Open Source Software: How do you put a Value on free?[END_REF], OSS projects often possess other assets, such as IPR, trademarks, brands or IT Infrastructure [START_REF] German | The GNOME project: a case study of open source, global software development[END_REF][START_REF] Fitzgerald | The transformation of open source software[END_REF]. However, there are plenty of opportunities for OSS projects to use IT Infrastructure from other organizations without possessing them (e.g. GitHub as a DVCS).

What de Laat [START_REF] De Laat | Governance of open source software: state of the art[END_REF] describes as institutionalization in order to involve outside parties, is what the legal entity is in our framework.

In their paper, Lindman and Hammouda [START_REF] Lindman | Investigating Relationships Between FLOSS Foundations and FLOSS Projects[END_REF] illustrate the role of OSS foundations and the relationships between OSS communities and other OSS foundations. Although their unit of analysis was OSS foundations, the taxonomy can be compared to the organizational framework in our study; each of their elements can also be found in our organizational framework.

Our framework describes the different elements comprised within a single OSS project and shows the broad variety and complex constellation surrounding such a project. However, as an example, an OSS community may have different projects (e.g. different software products with different goals) and therefore a project does not correspond to the organization (the three dimensions of our framework). Moreover, an umbrella organization such as the Linux Foundation may offer their legal entity in order to protect the project and to offer services relating those three dimensions of our framework. Therefore, the legal aspect of the organizations does not need to correspond to the project. We see our framework as a first step to better understand and differentiate the concepts and different elements in order to ask more specific questions relating OSS research.

Our organizational framework broadens the view of Riehle and Berschneider [49] that shows 3 different ways in which a mature OSS project can govern itself in the future: 1) continue as is, 2) create its own legal entity or 3) affiliate with an existing OSS foundation. In our view, in addition to these 3 forms, an "in-between" solution involving collaboration with different OSS foundations is also possible. Such collaboration can be in all areas of our organizational framework or in specific areas only. This is the case in the LibreOffice community which has its own legal entity (The Document Foundation), but buys some services in the funding process from another foundation [START_REF]Software in the Public Interest, Inc[END_REF].

For practitioners, our framework will help to provide a better understanding of the structure an OSS project can have and how the different elements can be organized, similar to an organization. Moreover, our framework can provide practitioners valuable insights on several managerial aspects relating to OSS governance.

Fig. 1 .

 1 Fig. 1. Organizational Framework.


Manon Fourniol

Valentin Gies

Valentin Barchasz

Edith Kussener

Hervé Barthelemy

Remy Vauché

Hervé Glotin

Low-Power Wake-Up System based on Frequency Analysis for Environmental Internet of Things

Being used in for environmental and military Internet of Things (IoT), a low power wake-up system based on frequency analysis is presented in this paper. It aims at detecting continuously the presence of specific very high frequencies in the input acoustic signal of an embedded system. This can be used for detecting specific animal species, and for triggering a recording system or generating alerts. Used for harmful species detection, this helps to save harvests or to protect strict nature reserves. It can also be used for detecting the presence of drones in a specific restricted area.

This acoustic low power wake-up system uses a simple 16 bits micro-controller (MCU), with a strong emphasis on the low power management of the system, having a target of continuous detection for at least one year on a single standard 1.2Ah -12V lead battery. For that, it makes the most of mixed analog and digital low power MCU modules. They are including comparators, timers and a special one present on Microchip MCU, called Charge Time Measurement Unit (CTMU). This is a driven constant current source for making time to frequency conversions at a very low power and algorithmic cost.

Optimizing low power modes, this low power wake-up system based on frequency analysis has a power consumption of 0.56mW , leading to approximately 3 years of battery life on a single standard 1.2Ah -12V lead cell.

Introduction

Environmental and military surveys can last several months without any human intervention, due to operational or environmental constraints such as installation of a device in a strict nature reserve or in a restricted access area which requires unmanned operations for long periods. This is hardly compatible with autonomous high frequency environmental recording systems, because power consumption is too important. For example, acoustic recording of animals such as bats or rats, having a communication and localization system emitting up to 120kHz [START_REF] Whitaker | National Audubon Society Field Guide to North American Mammals[END_REF] and aerial drones producing a characteristic noise around 40kHz [START_REF] Ganti | Implementation of detection and tracking mechanism for small UAS[END_REF], requires to have a data acquisition system working at a minimum of 240ksps with a resolution of 24 bits for detecting low level signal. This leads to store 2.5GB of data every hour. In order to add 3-dimensional source localization feature to these applications, 4 or 5 microphones are necessary, creating a huge quantity of 10GB of data every hour.

In these conditions, it is almost impossible to have a portable autonomous long term data acquisition system able to record continuously. Fortunately, continuous recording is mostly not necessary, but can be reduced to periods with interesting data.

In this paper we propose a solution that can be used in a common class of environmental issues : recording or analyzing acoustic signals emitted by animals or drones, by pre-filtering instants when they are present or suspected to be there. As an example, we coped with this issue for protecting a strict nature reserve island (Ilot Bagaud, part of the Parc National de Port Cros in France) from rats intrusions with the Qualilife system [START_REF] Smiot | Technical Report on High Frequency Recording Systems[END_REF] integrating the low power acoustic wake-up system shown in Fig. 1.

Figure 1: Low Power Acoustic Wake-Up System integrated in "Qualilife" recording system Rats intrusions have to be detected, recorded and also analyzed in order to send an alert message to the biologists monitoring the island or to local environmental authorities in real time [START_REF] Glotin | Analyse temps-réel de masse acoustique pour le suivi d'espèce nuisible à Port-Cros[END_REF]. Furthermore, the detection system has to work autonomously for at least 12 months because the area is strictly protected. In the case of aerial drone detection in a restricted military area, the wake-up system can be used for generating alerts in order to prevent malicious behaviors.

In these cases, continuous recording is not possible on a long term, due to the important power consumption of the high frequency 2 channels recording system : 500mW for signal capture and storage. We have to cope with an issue described in [START_REF] Gestner | Glass Break Detector Analog Front-End Using Novel Classifier Circuit[END_REF], [START_REF] Jeong | 21.6 A 12nW always-on acoustic sensing and object recognition microsystem using frequencydomain feature extraction and SVM classification[END_REF], [START_REF] Rumberg | Hibernets: Energy-Efficient Sensor Networks Using Analog Signal Processing[END_REF] and [START_REF] Dobre | Low computational method for siren detection[END_REF]. Our recording system is working on a standard 12V -1.2Ah lead battery having a global capacity of 14.4W h. In continuous recording, batteries would last only 30 hours, without including the energy necessary for processing signals and generating alerts. Considering that rats invasions are rare, we can assume that the maximum acceptable average power consumption is equal to the battery capacity divided by the needed autonomy of the system (i.e. 12 months). This leads to allow a power consumption of 1.6mW in continuous mode. Considering that each of our two microphones (necessary for 2D source localization) power supply draws 0.4mW , the available average power remaining for rats detection is 0.8mW . It is the same for aerial drones detection systems, considering intrusions are rare. The only difference is postprocessing : alarms are much more likely to be generated than acoustic recordings thus leading to activate advanced signal post-processing.

In order to store efficiently the high frequency acoustic signals occurring sparsely at a random time, we need to trigger the records at the moments where an interesting signal is present. This allows to avoid useless power consumption, useless data storage saturation, and useless post-processing work to rise alarms or to find out interesting events. Following the emerging idea of using edge computing techniques, this pre-filtering process allows to detect only the interesting events, and thus consuming less, saving a huge amount of data storage and making the device record for a long time.

Some low power wake-up systems based on raw frequency detection exist, like [START_REF] Höflinger | Smartphone remote control for home automation applications based on acoustic wake-up receivers[END_REF] but they are mainly specified on detecting a specific frequency and are specialized in radio frequency analysis in for example RFID technologies [START_REF] Sanchez | RFID Based Acoustic Wake-Up System for Underwater Sensor Networks[END_REF]. There are also some detectors using advanced digital processing techniques and having more developed capabilities such as pattern detection, like [START_REF] Ge | Deep neural network based wake-up-word speech recognition with twostage detection[END_REF] or [START_REF] Cauwenberghs | A miniature low-power intelligent sensor node for persistent acoustic surveillance[END_REF], but with a limited sampling frequency and at a higher overall power cost due to analog to digital conversions.

Acoustic Environmental Monitoring System Description

This paper focuses on the low power wake-up system based on frequency analysis, however a global description of the recording and analysis system is presented in Fig. 1. It explains how the acoustic low power wake-up system based on frequency analysis is connected with other parts of the high frequency recording system using a low power device. Then, the architecture and implementation of the wake-up system is presented and described precisely.

The global description of our acoustic recorder is shown in Fig. 2. Processing is done in three steps, each one having an increasing power cost :

• Signal from the microphone is first processed by the low power wake-up system which will wake up a supervisor with an interruption when the desired frequency is detected. This operation is performed in a continuous way at a very low energy cost of 13µW when there is no significant input signal, and is not exceeding 0.56mW in the most hard processing case (excluding microphone power supply) on a few peripherals of a micro-controller (MCU). This low power acoustic wake-up system is the main topic of this paper.

• Then the supervisor can activate advanced signal processing based on traditional linear or nonlinear filters, neural network, wavelets transforms and so on [START_REF] Kojima | Semi-automatic bird song analysis by spatial-cue-based integration of sound source detection, localization, separation, and identification[END_REF], [START_REF] Nakamura | Robot audition based acoustic event identification using a bayesian model considering spectral and temporal uncertainties[END_REF], [START_REF] Otsuka | Bayesian nonparametrics for microphone array processing[END_REF], [START_REF] Rybach | Silence is golden: Modeling nonspeech events in wfst-based dynamic network decoders[END_REF] and [START_REF] Chin | Audio event detection based on layered symbolic sequence representations[END_REF]. They are used to precisely characterize the detected signal and to validate its interest. These operations are performed on demand with the same MCU as before, with a more important power consumption of about 17.5mW at 16M IP S. The supervisor stage is also able to launch an alarm. It is interesting to notice that, depending on the signal interest, our low power wake-up system based on frequency analysis could be sufficient, as the high frequency (from 40 kHz to 200 kHz) will be rare in our environment which are far away from the human activities. This filtering stage is not the topic of this paper.

• Then, if the signal is analyzed as interesting, a high frequency and high quality recorder is started for a defined amount of time, in order to record the next occurrences of the interesting signal. It is important to notice that this way of proceeding cannot be used for recording one shot signals because signal used for low power acoustic wake-up is lost. A solution using an analogical to digital signal buffer converter could be implemented but would not be low power.

Low-Power Wake-Up System based on Frequency Analysis

This paper focuses on the low power wake-up system. Its architecture is simple as simplicity is a virtue for achieving a very low power detection working continuously on raw acoustic high frequency data. To limit power consumption, we have decided to implement it using an extra low power 16 bits MCU from Microchip [START_REF]Family : 16-Bit Flash Microcontrollers with Dual Partition Flash Memory, XLP, LCD, Cryptographic Engine and USB On-The-Go, DS30010089D datasheet[END_REF], having interesting low power mixed digital-analog peripherals. Implementation makes the most of peripherals autonomously used in order to reduce power consumption. Modules used are analog comparators, timers and a specific Microchip module : the Charge Time Measurement Unit (CTMU) [19] [20]. This is a very flexible mixed digital-analog module working as a configurable and externally triggerable current source that can be used to generate asynchronously controlled charges or discharges of capacitors.

Architecture Description

The proposed acoustic wake-up system based on frequency analysis is described in Fig. 3.

The processing system is precisely explained with chronograms in Fig. 4. First, acoustic signal U S incoming from a low power microphone (0.5mW ) enters the MCU by an analog comparator having an adjustable comparison level.

Output of the comparator is the signal U InCp entering a high frequency monostable timer. This monostable timer generates a pulse of fixed length T m on each rising edge of the signal U InCp , as shown on signal U m . At this step the moving average value of U m is almost proportional to the incoming frequency. However, filtering would introduce a delay and a loss of information we want to avoid.

Logical output U m of the monostable timer enters the CTMU module and activates the charge of a capacitor with a fixed current I 0 as long as the monostable is high. Hence, the capacitor voltage is growing linearly during these phases as shown on signal U C in Fig. 4. For a fixed amount of time, the higher the input frequency, the higher the capacitor voltage is. The Fig. 4 shows U C , the charge of the capacitor, becoming higher or smaller according to the U S frequency.

We introduce the following equation :

U C = t 0 I C (t) C dt = t 0 I 0 C U m (t)dt = I 0 C * N * T m (1) = I 0 C * F S F T rCp * T m (2)
where U m is a logical level 1 or 0 depending on the monostable output state, N the number of pulses between two successive resets, F T rCp the comparator trigger frequency, and F S is the input signal frequency. Simultaneously, a signal U T rCp is generated from a low frequency pulse generator, independently from U S and at a fixed frequency F T rCp It is used to periodically trigger analog voltage comparisons between the capacitor voltage and numerically defined fixed thresholds as described in fig. 5. These comparisons allow to know if the incoming signal frequency is lower or higher than reference frequencies, because analog output voltage U C value is proportional to F S as shown in equation 2.

Finally, capacitor is discharged (as shown in Fig. 5) by U Reset (Fig. 4) just after analog comparisons. This is done by switching numerically an internal NMOS to discharge the external capacitor of the CTMU module. U Reset is generated as a delayed signal from U T rCp numerically on the interrupt raised by the lower frequency timer.

As a final result, outputs of comparators 1 and 2 (respectively U OutCp1 and U OutCp2 on Fig. 5) give an accurate information on whether the input frequency is in a specific frequency band or not. This allows to activate further processes using more energy if incoming frequency matches the desired frequency, depending of the application, in order to confirm whether the input signal is interesting or not.

Implementation

In this section, the role and tuning of each part of the low power frequency wake up system is explained in details. As previously said, the purpose of our system is to be a low-power frequency wake up system, in order to keep the global recording system installation working for several months or years. To this end, we first chose a low-power MCU device, such as the PIC24FJ256GB410 from Microchip for his Extreme Low Power (XLP) processor. Indeed, this device power consumption is only 170µA per 1M Hz, is reduced to 4µA in Sleep Mode.

Input Comparator

A comparator is used to compare the input signal to a reference value. In our case, we use it to convert the signal from the microphone which can be very small to an exploitable digital input. The comparator voltage reference is a 16-tap, resistor ladder network that provides a software selectable reference voltage. Without using it, the input of the timer generating monostable signal would not trigger on each period of the input signal. Avoiding this is the role of the input comparator. However, there can be some side effects in case comparator level is not adjusted correctly, because comparator is a single one and not a Schmitt trigger with adjustable low and high thresholds. Fig. 6 shows two possible tunings of the trigger level. The first one leads to a good frequency measurement, whereas the second one leads to have two rising edges on the output for each signal period, leading to a wrong frequency measurement at the end. This can be avoided by a software algorithm comparing successive instant of comparator output rising edges. When there is a wrong measurement, time interval between two rising edges is variable (first comparison in Fig. 6). Whereas time interval between two rising edges is constant in case of no multi-detection (second comparison in Fig. 6).

High frequency monostable timer

The monostable is triggered by U InCp rising edges. Monostable duration T m must be adjusted carefully. Longer than input signal period T s , it leads to have rising edges arriving on the input whereas the output is still active as shown in Fig. 7. This rising edges will not be taken into account, thus leading to a wrong frequency evaluation.

A too small T m requires to have a higher frequency internal clock leading to a higher power consumption.

Finally, if the signal frequency is limited to 100kHz, choosing a monostable period of 2µs leads to an accurate estimate of the frequency up to 500kHz. This allows to cut the input signal having a frequency higher than 100kHz with a simple RC low pass filter, with an attenuation of about -14dB at 500kHz. This attenuation is sufficient for removing unwanted highest frequency signal components, like in anti-aliasing filters, without having a complex or power consuming analog active filter in input. Finally, this leads to have a system clock at 0.5M IP S with a timer counting up to 1 only, leading to a reduced power consumption of the processor of about 560µW . Increasing monostable period is possible to reduce system clock frequency, but at the price of filtering the input with a sharp analog anti-aliasing filter, leading to an important power consumption.

CTMU module

The CMTU module is a controlled current source. Charging an external capacitor, it is the heart of the system. U m is triggering the constant current charge periods of the capacitor, leading to phases of linear increase of the capacitor voltage U C as shown on Fig. 4. U C cannot exceed power supply voltage (V dd = 3.3V ), and thus needs to be reset periodically by U Reset at the frequency F T rCp . Tuning CTMU parameters is fundamental in order to reduce power consumption while having a precise measurement. In our application, we want to detect a high frequency signal at 100kHz. This detection is done at a frequency F T rCp = 1kHz, in order to have a good reactivity of the wake-up system. This leads to integrate N = 100 current pulses of duration T m = 2.10 -6 s between 2 resets as described in equation 1. Because U C cannot exceed V dd = 3.3V , this leads to :

I 0 C < V dd N * T m (3)
The CTMU current can be configured by software to 550µA, 55µA, 5.5µA or 550nA, leading respectively to minimum capacitor values of 33nF , 3.3nF , 330pF or 33pF according to equation 3. Choosing the minimum current leads to the lower power consumption, but in this case capacitor has to be very low in order to reach an acceptable voltage for further comparisons. This very low capacitor reduces the precision of the CTMU integrator, because parasitic capacitance and resistance are not taken into account, leading to both a precision and linearity error. It is better to charge a bigger capacitance in order to avoid these side effects, such as 470pF coupled with a current of 5.5µA. In this case the voltage obtained with an input signal at 100kHz is U C = 2.34V according to equation 2, with a limited current delivered by the CTMU.

Output Comparators

Just before reset, U C gives a good approximation of the average frequency of the input signal between the last reset and the future one as shown in equation 2. Therefore this value is to be used as an output of the system. Converting it into a digital value using the ADC module would draw to much energy, so it is more efficient to use comparators which are only activated just before the reset of U C and latched during the rest of the time.

Several comparators can be used in order to select a specific range of frequencies : for example one is activated when the measured frequency is lower than a specified value, and another one activated when the frequency is higher than another specified value, as shown in Fig. 5.

Configuration of the output comparators thresholds is done by software [START_REF]Microchip Technology Incorporated, Comparator Voltage Reference Module[END_REF], with a limited number of 32 evenly distributed voltage references between V ss = 0V and V dd = 3.3V . Detecting U C = 2.34V can be done by setting voltage references U OutCp1 = 2.37V for the high threshold, and U OutCp2 = 2.26V for the low threshold. This thresholds configuration will detect an input signal having its frequency between 96.5kHz and 101.3kHz. This selection band is very narrow compared to much more power consuming high order analog bandpass filters.

However, the selection band width is strongly related to the CTMU charge unit configuration described in 3.2.3. A too small current, or a too big capacitance would lead to reach a smaller analog value U C , requiring to reduce the level of the thresholds for a given input frequency. This would lead to decrease the precision of the selection band.

In conclusion of this part, knowing the frequency range of a signal is an important and useful information for indicating that there is a strong presumption that the input signal corresponds to something wanted. Then, more precise but more energy consuming operations can be triggered for checking the signal, but they are not in the field of this paper.

Low Power Management

In this paper, we aim at reducing drastically the power needed for detecting interesting signals happening rarely. Thus, low power mode management is important and described in this section.

Our MCU, a P IC24F J256GB410 has extended low power features. Power consumption in normal mode at 16 MIPS under 3.3V is 17.5mW , which is important compared with the microphone one (0.5mW ). In sleep mode, the MCU consumes 13µW .

Having the MCU in sleep mode most of the time is necessary to reduce power consumption. However, the monostable timer cannot be used in sleep mode, because system clock is stopped. Consequently, the MCU has to be active during monostable pulse generation. During this phase, system clock frequency has to be reduced to a minimum, having a period T cy corresponding to the duration of a monostable pulse. As explained before, that leads to operate at a system frequency F cy = 0.5M IP S, with a power consumption of 0.56mW . This low frequency mode is enabled while incoming signal is present, sleep mode is activated when there is no signal for 1 second.

As a result of this low power management scheme, even when incoming signal is always present (that could happen in windy environment for example), the power consumption of the wake-up detector (0.56mW ) is equivalent to the microphone power consumption (0.5mW ). Further improvement is possible to divide power consumption by 4 if the input frequency is lower than 100kHz, by activating the sleep mode between monostable pulses. This can be interesting when processing data from extremely low power sensors.

Current drawn by the CTMU module is not significant if the CTMU is set-up correctly has described in 3.2.3.

Results

One of the main goal of our frequency wake-up system is to process signal continuously with a limited power consumption. Every function has been optimized carefully for reducing it. Our system works with a limited power consumption of less than 0.6mW , not including the microphone, which can drop to 13µW in sleep mode.

This allows to use it to optimize drastically battery life in environmental IoT devices by selecting only the useful moments of the signal. Considering a system having two ultrasonic microphones to allow basic 2D source localization, each one consuming 0.5mW , and powering the system by a 14.5W h battery (classical 12V -1.2Ah lead battery), our wake-up system can be active about almost 3 years in continuous mode, compared with a 30 hours of continuous recording with most of the time no useful signal as explained in introduction.

Conclusion and future works

In this paper, we have presented a low power wake-up system based on frequency analysis which can be used as a first continuous signal processing stage for detecting the presence of a desired frequency in a signal.

Although the implementation is simple, it is very efficient when trying to record very high frequency environmental signals happening rarely. In theses situations, average power consumption of the recording system can be reduced by a factor 200 or more, and mass storages are filled only with potentially interesting data.

To go further, we are focusing on reducing power consumption of our wake-up system to use it with lower throughput data on very small embedded systems, such as wearable sensors for studying birds. In this case, power consumption for recording is reduced and the wake-up system power consumption has also to be reduced to make it still relevant. To achieve that, we will investigate for replacing the MCU by ultra low power discrete components in a first time, and by a silicon implementation in a second step. Furthermore, our system will be tested on submarine monitoring systems using hydrophones for detecting Mediterranean marine mammals in the Pelagos Sanctuary, a marine protected area.

Figure 2 :

 2 Figure 2: Global Project Description.

Figure 3 :

 3 Figure 3: System Architecture.

Figure 4 :

 4 Figure 4: Processing System Description.

Figure 5 :

 5 Figure 5: Comparator Selection.

Figure 6 :

 6 Figure 6: Signal Selection by the First Comparator

Figure 7 :

 7 Figure 7: Monostable Overlapping at High Frequency

Figure 8 :

 8 Figure 8: CTMU Principle Overview [21]

Acknowledgment

The authors would like to thank the Parc National de Port Cros in France for their cooperation in the development and use of our recording systems and acoustic wake-up systems.

The authors would particularly like to thank the Embedded Electronics Technology Platform of Toulon University named SMIoT ( Scientific Microsystems for Internet of Things) [23] for its support in the achievement of the system.