KR102045892B1 - Development assistant apparatus of mobile sensing application, development assistant system having the same, method of assisting development of mobile sensing application using the same - Google Patents

Development assistant apparatus of mobile sensing application, development assistant system having the same, method of assisting development of mobile sensing application using the same Download PDF

Info

Publication number
KR102045892B1
KR102045892B1 KR1020170116687A KR20170116687A KR102045892B1 KR 102045892 B1 KR102045892 B1 KR 102045892B1 KR 1020170116687 A KR1020170116687 A KR 1020170116687A KR 20170116687 A KR20170116687 A KR 20170116687A KR 102045892 B1 KR102045892 B1 KR 102045892B1
Authority
KR
South Korea
Prior art keywords
power
sensor
mobile sensing
sensing application
emulator
Prior art date
Application number
KR1020170116687A
Other languages
Korean (ko)
Other versions
KR20190029298A (en
Inventor
송준화
민철홍
이승철
이창훈
이영기
강승우
최승표
김원중
Original Assignee
한국과학기술원
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 한국과학기술원 filed Critical 한국과학기술원
Priority to KR1020170116687A priority Critical patent/KR102045892B1/en
Publication of KR20190029298A publication Critical patent/KR20190029298A/en
Application granted granted Critical
Publication of KR102045892B1 publication Critical patent/KR102045892B1/en

Links

Images

Classifications

    • G06F17/5009
    • G06F2217/78

Abstract

Development aids for mobile sensing applications include operating environment data domains, user interfaces, emulation managers, power emulators, and power analyzers. The operating environment data area stores the executable file of the mobile sensing application and the sensor trace collected from the user's mobile device. The user interface receives a power evaluation request from the developer, and outputs a power analysis result in response to the power evaluation request. The emulation manager controls the power emulation operation by receiving executable files of the mobile sensing application and user's sensor traces and power evaluation requests. The power emulator uses the user's sensor traces to emulate the power usage of mobile sensing applications. The power analyzer converts the emulation results of the power emulator into a power analysis report.

Figure R1020170116687

Description

DEVELOPMENT ASSISTANT APPARATUS OF MOBILE SENSING APPLICATION, DEVELOPMENT ASSISTANT SYSTEM HAVING THE SAME, METHOD OF ASSISTING DEVELOPMENT OF MOBILE SENSING APPLICATION USING THE SAME}

The present invention relates to a development assistance apparatus for a mobile sensing application, a development assistance system including the same, and a development assistance method using the same. More particularly, the development assistance apparatus for a mobile sensing application capable of effectively predicting power consumption of the mobile sensing application; The present invention relates to a development assistance system including the same and a development assistance method using the same.

When developing mobile-sensing applications, developers must be aware of power consumption awareness, which places a significant burden on power consumption prediction.

Due to the nature of the mobile sensing application that requires a great deal of attention on power consumption, the developers can measure the mobile sensing through iterative power consumption evaluation such as power measurement, identification of power sensitive code blocks, change of logic or tuning of power related parameters. You can optimize the power usage of your application.

However, since the power usage of the user has many variables according to various situations occurring to the user in real life, the repeated power consumption evaluation may be a heavy burden on the developer.

In addition, even a single assessment of the power usage of the mobile sensing application is cumbersome and time consuming. For example, for a realistic power consumption test, the developer should consider a real life usage scenario of the mobile sensing application.

In the real world, developers often deal with ad hoc rather than seriously considering power requirements due to the lack of development support tools.

An object of the present invention for solving the above problems is to provide a development assistance device of a mobile sensing application that can effectively predict the power consumption.

Another object of the present invention is to provide a development assistance system including the development assistance apparatus.

Still another object of the present invention is to provide a development assistance method using the development assistance apparatus.

According to one or more exemplary embodiments, a device for developing a mobile sensing application includes an operating environment data area, a user interface, an emulation manager, a power emulator, and a power analyzer. The operating environment data area stores an executable file of the mobile sensing application and sensor traces collected from a user's mobile device. The user interface receives a power evaluation request from a developer, and outputs a power analysis result in response to the power evaluation request. The emulation manager controls the power emulation operation by receiving the executable file of the mobile sensing application, the sensor trace of the user, and the power evaluation request. The power emulator uses the sensor trace of the user to emulate the power usage of the mobile sensing application. The power analyzer converts the emulation result of the power emulator into a power analysis report.

In one embodiment of the present invention, the user interface may include a first input unit for uploading the executable file of the mobile sensing application and a second input unit for selecting the sensor trace.

In one embodiment of the present invention, the user interface may display an in-depth analysis report corresponding to one power evaluation request. The depth analysis report includes a first display showing an overview of power usage, a second display showing a graph of power usage over time, a third display showing a graph of the behavior of hardware components over time, and context-labeled information. And a fourth display unit indicating the custom log message.

In one embodiment of the invention, the overview of power usage may include average power usage, total wakelock time, total number of alarms, and total activation time of the hardware components.

In one embodiment of the present invention, the hardware components may include a CPU, a GPS sensor, a microphone, and a Bluetooth device.

In one embodiment of the present invention, the custom log message may use APIs of Log.p (tag, msg) and Log.p (tag, msg, isOn). The Log.p (tag, msg) may display a log message related to power at a specific time point, and the Log.p (tag, msg, isOn) may display the log message related to the power in a time range. The tag is for identifying the source of the log message, the msg indicates a message to be logged, and the isOn may mean the start and end of the time range.

In one embodiment of the present invention, the user interface may present a comparative analysis report that compares power items according to a plurality of power evaluation requests. Power items of interest to the developer may be selected by the developer to optimize the comparative analysis report.

In one embodiment of the present invention, the power evaluation requests may correspond to application settings.

In one embodiment of the present invention, the application setting may include a parameter type and candidate values corresponding to the parameter type. The number of power evaluation requests may be determined by all combinations of the number of parameter types and the candidate values corresponding to the parameter type.

In one embodiment of the present invention, the emulation manager may generate a plurality of power emulators equal to the number of power evaluation requests.

In one embodiment of the present invention, the emulation manager may allocate the sensor trace segments to the power emulator by dividing the sensor trace into a plurality of sensor trace segments.

In one embodiment of the invention, the power emulator is a sensor emulator that mimics the operation of the sensor of the mobile device based on the sensor trace, the mobile sensing application and another mobile based on the device usage trace of the mobile device. It may include a device notice replayer that reflects the device sharing effect of the application and a hardware notice monitor that collects hardware usage statistics.

In one embodiment of the present invention, the power emulator may further include a time accelerator for skipping the idle time of the sensor trace during operation of the sensor emulator, in order to reduce the operating time of the power emulator.

The development assistance system of a mobile sensing application according to an embodiment for achieving the above object of the present invention includes a sensor trace collector and a development assistance device of a mobile device. The sensor trace collector generates a sensor trace of a user. The development assistant includes an operating environment data area, a user interface, an emulation manager, a power emulator, and a power analyzer. The operating environment data area stores an executable file of the mobile sensing application and the sensor trace. The user interface receives a power evaluation request from a developer, and outputs a power analysis result in response to the power evaluation request. The emulation manager controls the power emulation operation by receiving the executable file of the mobile sensing application, the sensor trace of the user, and the power evaluation request. The power emulator uses the sensor trace of the user to emulate the power usage of the mobile sensing application. The power analyzer converts the emulation result of the power emulator into a power analysis report.

According to an embodiment of the present invention, a method for supporting development of a mobile sensing application includes: receiving an executable file of a mobile sensing application, receiving a sensor trace collected from a mobile device of a user, Receiving a power evaluation request, generating a power emulator based on the power evaluation request, power of the mobile sensing application based on the executable file of the mobile sensing application and the sensor trace of the user and the power evaluation request Emulating the use, converting the emulation result into a power analysis report, and outputting the power analysis report.

The development assistance apparatus, the development assistance system, and the development assistance method of the mobile sensing application according to the embodiment of the present invention may help a developer to recognize power consumption in the development of the mobile sensing application.

The development assistant may provide the developer with a power emulation environment that can simultaneously reproduce the codes.

The development assistant device may accurately determine the power consumption of the mobile sensing application in a development environment without executing the mobile sensing application directly on the mobile device and measuring power consumption. In addition, the development assistant may estimate power consumption based on various input workloads reflecting usage scenarios in the real world. In addition, the development assistant provides abundant power consumption information over a timeline for each hardware component, thereby enabling the developer to understand the power usage of the mobile sensing application.

The development assistant can reduce the burden of repeated power measurements according to actual usage scenarios, provide information on rich and detailed power consumption along the timeline, and ensure repetitive power decisions for the same scenarios. I can do it.

1 is a block diagram illustrating a development assistance system of a mobile sensing application according to an embodiment of the present invention.
FIG. 2 is a conceptual diagram illustrating a power evaluation request of the development assistance system of FIG. 1.
3 is a block diagram illustrating the power emulator of FIG. 1.
4 is a block diagram illustrating an emulator instance of FIG. 3.
5 is a conceptual diagram illustrating a detailed power analysis of the development assistance system of FIG. 1.
6 is a conceptual diagram illustrating a power comparison analysis of the development assistance system of FIG. 1.
FIG. 7 is a conceptual diagram illustrating setting of a mobile sensing application used in the development assistance system of FIG. 1.
FIG. 8 is a graph illustrating the accuracy of power prediction of the development assistance system of FIG. 1.

With respect to the embodiments of the present invention disclosed in the text, specific structural to functional descriptions are merely illustrated for the purpose of describing embodiments of the present invention, embodiments of the present invention may be implemented in various forms and It should not be construed as limited to the embodiments described in.

As the inventive concept allows for various changes and numerous embodiments, particular embodiments will be illustrated in the drawings and described in detail in the text. However, this is not intended to limit the present invention to the specific disclosed form, it should be understood to include all modifications, equivalents, and substitutes included in the spirit and scope of the present invention. In describing the drawings, similar reference numerals are used for the components.

Terms such as first and second may be used to describe various components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, the first component may be referred to as the second component, and similarly, the second component may also be referred to as the first component.

When a component is said to be "connected" or "connected" to another component, it may be directly connected to or connected to that other component, but it may be understood that other components may exist in the middle. Should be. On the other hand, when a component is said to be "directly connected" or "directly connected" to another component, it should be understood that there is no other component in between. Other expressions describing the relationship between components, such as "between" and "immediately between" or "neighboring to" and "directly neighboring", should be interpreted as well.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this application, the terms "comprise" or "have" are intended to indicate that there is a feature, number, step, action, component, part, or combination thereof that is described, and that one or more other features or numbers are present. It should be understood that it does not exclude in advance the possibility of the presence or addition of steps, actions, components, parts or combinations thereof.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art. Terms such as those defined in the commonly used dictionaries should be construed as having meanings consistent with the meanings in the context of the related art and shall not be construed in ideal or excessively formal meanings unless expressly defined in this application. Do not.

Hereinafter, with reference to the accompanying drawings, it will be described in detail a preferred embodiment of the present invention. The same reference numerals are used for the same components in the drawings, and duplicate descriptions of the same components are omitted.

1 is a block diagram illustrating a development assistance system of a mobile sensing application according to an embodiment of the present invention.

Referring to FIG. 1, the development assistance system of the mobile sensing application includes a development assistance device 100 and a sensor trace collector 200.

The development assistance system uses an emulation method based on traces to predict power consumption of a mobile sensing application.

The development assistance system outputs the power analysis result to the developer in response to a request from a developer who develops the mobile sensing application.

The core design approach to satisfy the design requirements of the development assistance system is a context-driven record-and-replay approach.

The development assistance system provides a power emulation environment in which the developer can simultaneously reproduce the codes of the mobile sensing application. The power emulation may be performed based on sensor data previously obtained from a user's actual situation.

The development assistance system reproduces a target mobile sensing application on the sensor data and emulates the power of the target mobile sensing application. Thus, the development assistance system allows the developer to analyze the power usage of the target mobile sensing application without repeated experiments and measurements.

For example, compared to current development practices that actually require code execution on mobile devices for power usage analysis of mobile sensing applications, the emulation-based development assistance system has the following advantages.

First, the development assistance system relieves the burden of the developer because it eliminates the annoyance of running and observing an application for a long time in a real life usage scenario.

Second, by comparing the power usage of different application logic in the same situation, the development assistance system enables iterative power evaluation. Similar attempts can generate different sensor data, which can change the power usage of mobile sensing applications.

Third, the development assistance system enables fast and scalable power evaluation. Therefore, the development assistance system may be applicable to a cloud environment.

1 shows the overall configuration of the development assistance system. The development assistance system may include a development assistance device 100 and a sensor trace collector 200. The development assistance apparatus 100 includes operating environment data 110, a user interface 120, an emulation manager 130, a power emulator 140, and a power analyzer 150.

The operating environment data 110 may include a sensor trace labeled with a context, an application executable file, and a power evaluation setting. The sensor traces may be collected from the sensor trace collector 200 disposed within the user's mobile device. The application execution file and the power evaluation setting may be input from the developer.

The user interface 120 may also be called a PADA front end. The user interface 120 may include an interface through which a developer may input a power evaluation request and an interface through which a power analysis result may be checked. For example, the user interface 120 may be a web-based interface.

The emulation manager 130 controls the power emulation operation. The emulation manager 130 may receive a power evaluation request from the user interface 120. The emulation manager 130 may distribute the power evaluation requests to a plurality of power emulators 140.

For example, the emulation manager 130 may generate a plurality of power emulators 140 equal to the number of power evaluation requests.

Each power emulator 140 emulates power usage of the target mobile sensing application using selected sensor traces. The power emulator 140 outputs an emulation result to the power analyzer 150.

The power analyzer 150 converts the emulation result obtained from the power emulator 140 into a power analysis report.

The development assistance system may further include supplementary application programming interfaces (APIs). The auxiliary API makes it possible to take advantage of the features of the development assistance system, such as configuration changes and custom logging.

The sensor trace may be collected once by the sensor trace collector 200 of the user's mobile device prior to the developer's power evaluation request, and the collected sensor trace may be reused according to the requests.

FIG. 2 is a conceptual diagram illustrating a power evaluation request of the development assistance system of FIG. 1.

1 and 2, FIG. 2 illustrates an interface for registering a new power evaluation request. The main purpose of the interface is to allow the developer to enter power evaluation requests for various execution scenarios with minimal effort.

The power evaluation request input method is as follows. First, the developer uploads an application executable file (part (a) of FIG. 2). For example, the developer can upload an application executable file in a drag and drop manner. Secondly, the developer selects a sensor trace for the environment in which the application can run (part (b) of FIG. 2). For example, the developer can select a plurality of sensor traces. Third, when the developer wants to test the mobile sensing application on various settings of the application, the developer may upload a configuration file. Once the configuration file is uploaded, the development assistance system automatically generates a plurality of application executable files and executes the application executable files at various designated settings. The development assistance system enables parallel registration of a plurality of power evaluation requests for the power evaluation.

3 is a block diagram illustrating the power emulator of FIG. 1. 4 is a block diagram illustrating an emulator instance of FIG. 3.

1 to 4, the power emulator 140 includes an emulator pool including a plurality of emulator instances EI.

The plurality of emulator instances EI may perform parallel emulation.

The emulation manager 130 receives the sensor trace, the application executable file and the evaluation setting from the operating environment data 110 and provides them to the emulator instances EI. Although not shown, the emulation manager 130 may further receive a device usage trace indicating the state of the mobile device of the user.

The emulation manager 130 may allocate the sensor trace segments to the emulator instances EI by dividing the sensor usage trace into a plurality of sensor trace segments.

The emulation manager 130 may divide the device usage trace into a plurality of device trace segments and assign the device trace segments to the emulator instances EI.

The emulation manager 130 may sum hardware usage statistics segments generated in the emulator instances EI based on the divided sensor trace segments.

The emulator instance EI includes a sensor emulator 300, a device visitor replayer 400, and a hardware visitor monitor 500.

The sensor emulator 300 mimics the operation of the sensor of the mobile device based on the sensor usage trace in response to a request of the mobile sensing application.

The device notice replayer 400 reflects device sharing effects of the mobile sensing application and other mobile applications based on the device usage trace. The device notice replayer 400 reproduces a situation in which the emulator instance EI executes several applications at the same time based on the device usage trace.

The hardware presence monitor 500 collects the hardware usage statistics.

The process of power emulation proceeds in three steps: pre-emulation, power emulation, and post-emulation.

In the pre-emulation step, the emulation manager 130 prepares inputs required for emulation upon request. The emulation manager 130 first receives a sensor usage trace from the operating environment data 110. In addition, the emulation manager 130 receives an executable file of the target mobile sensing application from the operating environment data 110. The emulation manager 130 initializes emulator instances EI operating in parallel to prevent delays in power consumption prediction. Each emulator instance EI installs a target mobile sensing application and receives the sensor usage trace and the required portion of the device usage trace from the emulation manager 130. The emulator instances EI may reproduce the user interaction, if necessary, before executing the target mobile sensing application. For example, the user interaction may be to click a start button to bootstrap a target mobile sensing application. In addition, the emulator instances EI may adjust the system clock to synchronize time with the traces.

When the preparation step is finished, in the power emulation step, the emulator instance EI executes the target mobile sensing application. While the target mobile sensing application is running, the sensor emulator 300 uses the collected sensor usage traces to mimic the operation of the sensor in response to a sensor usage request of the target mobile sensing application. To take into account the effect of sharing the device with other applications, the device notice replayer 400 uses the collected device usage traces to reproduce the device usage of running applications. This reproduces a situation in which the target mobile sensing application is executed together with another application. While the target mobile sensing application is running, the hardware notice monitor 500 tracks system calls for using hardware components such as sensors and CPU. Finally, the hardware presence monitor 500 generates hardware usage statistics. The hardware usage statistics include a series of system calls and corresponding timestamps executed while the target mobile sensing application is running.

The sensor emulator 300 reproduces the physical situation of the user by providing a sensor usage trace of the user to the target mobile sensing application. For realistic emulation, the sensor emulator 300 must provide the sensor data to the target mobile sensing application at the correct rate at the exact timing required by the target mobile sensing application. The sensor emulator must also emulate the hardware state of the corresponding sensor device.

The sensor emulator 300 mimics the operation and state of an actual sensor device. First, the sensor emulator 300 provides the target mobile sensing application with sensor data collected in advance according to the request of the target mobile sensing application. Second, the sensor emulator 300 reproduces system events associated with the sensor for correct operation of the target mobile sensing application. Third, the sensor emulator 300 tracks changes in the state of the sensor device through system call and callback logs associated with sensors sent to or returned from the kernel.

The sensor emulator 300 may be disposed between the Android framework and the kernel. The Android framework receives sensor data requests from multiple applications and interacts with the kernel. The sensor emulator 300 obtains system calls associated with sensors going from the framework to the kernel, and provides sensor data using the collected sensor usage traces.

The device notice replayer 400 reproduces a user's mobile device usage pattern to reflect the power sharing effect between applications in power emulation. For example, the device notice replayer 400 may operate in the background at the same time as the target mobile sensing application.

During power emulation, the hardware presence monitor 500 collects the hardware usage statistics. For example, the hardware notice monitor 500 may collect a system call generated by the framework and a timestamp of the system call. System calls associated with the sensor are collected at the sensor emulator 300.

For example, to calculate the power usage of the CPU, the hardware notice monitor 500 may take wakelock requests such as acquire_wake_lock () and release_wake_lock () that are sent from the Android PowerManager to the kernel. The hardware notice monitor 500 may obtain the CPU usage history of the target mobile sensing application from the acquire request of the wakelock to the release request of the wakelock.

After power emulation, the power analyzer 150 calculates net power increment netPapp by the target mobile sensing application based on the hardware usage statistics. The net power increase netPapp is calculated by Equation 1.

[Equation 1]

netPapp = P D with_app P D without_app

Here, D means a set of hardware components used by the target mobile sensing application. P D with_app means power consumption of D when the target mobile sensing application is executed. P D without_app means power consumption of D when the target mobile sensing application is not executed. As described above, the hardware component may be a CPU, GPS, Bluetooth, Wi-Fi, a microphone, an accelerometer, a gyroscope, a magnetometer, or the like.

The emulator instance EI may further include a time accelerator 600 for an idle time skipping scheme. The time accelerator 600 may skip the idle time of the sensor use trace during the operation of the sensor emulator 300 in order to reduce the operating time of the power emulator 140. The time accelerator 600 may determine the idle time of the sensor usage trace from a power manager of an operating system managing a wakelock.

In one embodiment of the present invention, the emulator instance (EI) may not include the configuration of the device stay replayer 400, for simplicity of the system.

In one embodiment of the present invention, the emulator instance (EI) may not include the configuration of the time accelerator 600, in order to simplify the system.

5 is a conceptual diagram illustrating a detailed power analysis (depth analysis) of the development assistance system of FIG. 1. 6 is a conceptual diagram illustrating a power comparison analysis of the development assistance system of FIG. 1.

1 to 6, the development assistance system may generate two kinds of power analysis reports. The first may be an in-depth analysis report and the second may be a comparative analysis report.

The depth analysis report includes detailed power information for one request. The depth analysis report includes the following four sections.

First, the depth analysis report shows an overview of power usage (part (a) of FIG. 5). The power usage summary includes the average power usage (mW), the total wake clock time, the total number of alarms and the total activation time of each hardware component. Secondly, the depth analysis report graphs power usage over time (part (b) of Figure 5). Third, the depth analysis report shows the behavior of each hardware component over time as a graph including color bars (part (c) of FIG. 5). For example, the hardware components may be a CPU, a GPS sensor, a microphone and a Bluetooth device. The information allows the developer to gain a holistic understanding of the power usage characteristics of the mobile sensing application.

The depth analysis report may further display the context labeled information and the custom log message (part (d) of FIG. 5). This information makes it possible to determine in which user's context the mobile sensing application uses a lot of power and which part of the application logic has a greater impact on overall power usage. Power usage of the mobile sensing application may vary greatly depending on the context of the user.

The development assistance system provides an interface for comparing key power items, such as average power consumption and hardware utilization, according to a plurality of power evaluation requests. 6 shows an example of a comparative analysis report. For example, the comparative analysis report indicates the average power consumption (avg. Power) of the mobile device, the wakelock time and GPS time of the application. The developer can select the power items of interest to optimize the comparative analysis report.

The comparative analysis report shows the characteristic advantages of the development assistance system. Through the comparative analysis report, it is possible to obtain a result of repeating several power evaluations within exactly the same sensor traces. In fact, it takes a lot of time and effort of the developer to set up the same situation repeatedly. In addition, the developer must simulate exactly the same situation, which not only requires a lot of time and effort, but can also be physically impossible.

The comparative analysis report may be useful in several situations as follows. Even in a worst-case scenario, in order to optimize power consumption, the developer may need to find a specific situation where power consumption is high. In addition, after adding new functions or changing parameters, it may be necessary to investigate the effect of such modifications on power consumption. The comparative analysis report of the development assistance system can help make an appropriate decision in making modifications to the application.

FIG. 7 is a conceptual diagram illustrating setting of a mobile sensing application used in the development assistance system of FIG. 1.

1 to 7, the development assistance system includes a plurality of assistance APIs. Developers often vary the application settings, comparing the power usage of the mobile sensing application. For example, suppose a developer determines the power usage of the mobile sensing application for ten different situations. For example, the developer may attempt to find the most suitable parameter while changing the sampling rate and monitoring interval of the sensor. However, manually building application executables for different application settings and comparing their power usage results is cumbersome.

In the development assistance system, a developer may first set parameter types and candidate values in a configuration file. In accordance with the power evaluation request, the development assistance system automatically generates the executable files for all combinations of the parameters. 7 shows an example of the configuration file. Three candidate values are set for a parameter type of location_interval in the configuration file (parameter.xml). The development assistance system generates the executable files, and when each executable file is executed, the getParameterValue () function returns the three candidate values one by one.

To assist the developer in matching the hardware usage of the mobile sensing application with the associated source codes, the development assistance system includes two types of logging APIs (Log.p (tag, msg), Log.p (tag, msg). , isOn)).

Log.p (tag, msg) is for displaying a log message related to power at a specific time point, and Log.p (tag, msg, isOn) is for displaying a message as a time range. Here, tag is used to identify the source of the log message, msg represents a message to be logged, and isOn means the start and end of the time range.

The log message is collected during power emulation of the mobile sensing application, after which the log message is displayed along with the hardware usage and power usage information as shown in FIG.

If the developer wants to find a portion of the source code that does not properly release the wakelock, the developer may insert a log message each time the wakelock is obtained. Through this, it is possible to determine the location of the problem wake call in the source code.

Before using the development assistance system, the developer may collect sensor traces according to real life sensor use scenarios. The sensor trace may be represented as a collection of sensor data and events collected from a sensor of the mobile device over time. If necessary, the context information may be additionally labeled. Which traces should be collected in the scenario should reflect the purpose of the power test of the mobile sensing application. For example, for a location tracking mobile sensing application, GPS should only be activated when the user is moving.

In addition, the developer may want to test the mobile sensing application in scenarios such as 'a standing state' and 'a state of walking and stopping for 5 minutes'. In addition, the developer may consider a scenario of a target user during the day for power tuning of the mobile sensing application. For example, the developer may consider a scenario of a weekend day of 20 college students and a scenario of a weekday of 30 office workers. The developer can then observe the power usage of the mobile sensing application while changing the sensing parameters.

The sensor trace 200 of the mobile device may collect sensor traces of interest to the developer. The developer specifies the type of sensor and the sampling rate of the sensor required for the execution of the mobile sensing application. The collected traces can be reused throughout the development process.

The developer can also collect sensor data of all available sensors of the mobile device at the maximum sampling rate to generate traces that can be commonly used in different mobile sensing applications.

For example, for power emulation of the mobile sensing application, the emulation manager 130 can be executed using a Java spring framework on the server. The power emulator 140 may receive a sensor trace and an application executable file. Thereafter, the power emulator 140 executes an application while reproducing the sensor trace and monitors hardware utilization. The power emulator 140 outputs system call events and predicted power consumption over time by the application.

For power emulation of the present invention, the power emulator 140 may be installed on an Android framework. In order to run the target mobile sensing application on the power emulator 140, the power emulator 140 hooks a system call made by a SensorManager within the Android framework. The power emulator 140 provides sensor values obtained from pre-collected sensor traces in response to a request of the target application.

When the target mobile sensing application is running, the power emulator 140 records system calls related to power usage (eg, GPS_on (), GPS_off () of the GPS device). When the emulation ends, the power analyzer 150 calculates the power consumption of the application based on the system call.

FIG. 8 is a graph illustrating the accuracy of power prediction of the development assistance system of FIG. 1.

1-8, FIG. 8 illustrates the accuracy of power prediction for various mobile sensing applications. For three commercial mobile sensing applications (App1: Accupedo, App2: Pedometer 2.0, App3: SleepBot) and one open source mobile sensing application (App4: Android-pedometer) and one research mobile sensing application (App5: iTRACK) We measured the accuracy of the power forecast. Groundtruth data were measured using a Monsoon power monitor running a Nexus 5 (Android 4.4) in a one hour real life scenario.

As shown in Figure 8, the accuracy of power prediction of the development assistance system according to the present invention recorded an average of 95.9%.

According to the present embodiment, the development assistance device, the development assistance system, and the development assistance method may help a developer to recognize power consumption in the development of the mobile sensing application.

The development assistant may provide the developer with a power emulation environment that can simultaneously reproduce the codes.

The development assistant device may accurately determine the power consumption of the mobile sensing application in a development environment without executing the mobile sensing application directly on the mobile device and measuring power consumption. In addition, the development assistant may estimate power consumption based on various input workloads reflecting usage scenarios in the real world. In addition, the development assistant provides abundant power consumption information over a timeline for each hardware component, thereby enabling the developer to understand the power usage of the mobile sensing application.

The development assistant can reduce the burden of repeated power measurements according to actual usage scenarios, provide information on rich and detailed power consumption along the timeline, and ensure repeated power judgments for the same scenarios. I can do it.

According to the present invention, the developer can efficiently predict the power consumption of the mobile sensing application during the development of the mobile sensing application.

As described above, the present invention has been described with reference to a preferred embodiment of the present invention, but those skilled in the art may vary the present invention without departing from the spirit and scope of the present invention as set forth in the claims below. It will be understood that modifications and changes can be made.

100: development assistant device 110: operating environment data
120: user interface 130: emulation manager
140: power emulator 150: power analyzer
200: sensor trace collector 300: sensor emulator
400: device presence replayer 500: hardware presence monitor
600: time accelerator

Claims (15)

An operating environment data area for storing an executable file of a mobile sensing application and sensor traces collected from a user's mobile device;
A user interface for receiving a power evaluation request from a developer and outputting a power analysis result in response to the power evaluation request;
An emulation manager that receives the executable file of the mobile sensing application, the sensor trace of the user, and the power evaluation request to control a power emulation operation;
A power emulator emulating the power usage of the mobile sensing application using the sensor trace of the user; And
A power analyzer converting the emulation result of the power emulator into a power analysis report,
The user interface represents an in-depth analysis report corresponding to one power evaluation request,
The depth analysis report includes a second display unit for graphing power usage over time and a third display unit for graphing the operation of hardware components over time.
The apparatus of claim 1, wherein the user interface comprises a first input unit for uploading the executable file of the mobile sensing application and a second input unit for selecting the sensor trace. 2. The development assistant of claim 1, wherein the depth analysis report further comprises a first display indicating an overview of power usage and a fourth displaying a context-labeled information and a custom log message. Device. 4. The apparatus of claim 3, wherein the overview of power usage includes average power usage, total wakelock time, total number of alarms, and total activation time of the hardware components. . 4. The development assistant of claim 3, wherein the hardware components include a CPU, a GPS sensor, a microphone, and a Bluetooth device. The method of claim 3, wherein the custom log message uses APIs of Log.p (tag, msg) and Log.p (tag, msg, isOn),
The Log.p (tag, msg) displays a log message related to power at a specific time point, and the Log.p (tag, msg, isOn) displays the log message related to the power in a time range,
The tag is for identifying the source of the log message, the msg represents a message that you want to log, the isOn means the start and end of the time range of the development assistance device of the mobile sensing application.
The method of claim 1, wherein the user interface presents a comparative analysis report that compares power items according to a plurality of power rating requests,
And the power items of interest to the developer are selected by the developer to optimize the comparative analysis report.
The apparatus of claim 7, wherein the power evaluation requests correspond to application settings. The method of claim 8, wherein the application setting comprises a parameter type and candidate values corresponding to the parameter type.
Wherein the number of power evaluation requests is determined by all combinations of the number of parameter types and the candidate values corresponding to the parameter type.
10. The apparatus of claim 9, wherein the emulation manager generates a plurality of power emulators equal to the number of power evaluation requests. The apparatus of claim 10, wherein the emulation manager divides the sensor trace into a plurality of sensor trace segments and allocates the sensor trace segments to the power emulators. 12. The system of claim 11, wherein the power emulator is
A sensor emulator that mimics the operation of the sensor of the mobile device based on the sensor trace;
A device usage replayer that reflects device sharing effects of the mobile sensing application and other mobile applications based on device usage traces of the mobile device; And
And a hardware presence monitor for collecting hardware usage statistics.
13. The system of claim 12, wherein the power emulator is
And a time accelerator for skipping the idle time of the sensor trace during operation of the sensor emulator to reduce the operating time of the power emulator.
A sensor trace collector of the mobile device to generate a sensor trace of the user; And
An operating environment data area for storing an executable file of the mobile sensing application and the sensor trace; A user interface for receiving a power evaluation request from a developer and outputting a power analysis result; An emulation manager configured to control a power emulation operation by receiving the executable file of the mobile sensing application, the sensor trace of the user, and the power evaluation request; A power emulator that emulates power usage of the mobile sensing application using the user's sensor traces; And a development assistant including a power analyzer converting the emulation result of the power emulator into a power analysis report.
The user interface represents an in-depth analysis report corresponding to one power evaluation request,
The depth analysis report includes a second display unit for graphing power usage over time and a third display unit for graphing the operation of hardware components over time.
Receiving an executable file of a mobile sensing application;
Receiving a sensor trace collected from a user's mobile device;
Receiving a power evaluation request from a developer using a user interface;
Generating a power emulator based on the power evaluation request;
Emulating power usage of the mobile sensing application based on the executable file of the mobile sensing application and the sensor trace of the user and the power evaluation request;
Converting an emulation result of the power emulator into a power analysis report; And
Outputting the power analysis report,
The user interface represents an in-depth analysis report corresponding to one power evaluation request,
The depth analysis report includes a second display unit for graphing power usage over time and a third display unit for graphing the operation of hardware components over time.
KR1020170116687A 2017-09-12 2017-09-12 Development assistant apparatus of mobile sensing application, development assistant system having the same, method of assisting development of mobile sensing application using the same KR102045892B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020170116687A KR102045892B1 (en) 2017-09-12 2017-09-12 Development assistant apparatus of mobile sensing application, development assistant system having the same, method of assisting development of mobile sensing application using the same

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020170116687A KR102045892B1 (en) 2017-09-12 2017-09-12 Development assistant apparatus of mobile sensing application, development assistant system having the same, method of assisting development of mobile sensing application using the same

Publications (2)

Publication Number Publication Date
KR20190029298A KR20190029298A (en) 2019-03-20
KR102045892B1 true KR102045892B1 (en) 2019-11-18

Family

ID=66036159

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020170116687A KR102045892B1 (en) 2017-09-12 2017-09-12 Development assistant apparatus of mobile sensing application, development assistant system having the same, method of assisting development of mobile sensing application using the same

Country Status (1)

Country Link
KR (1) KR102045892B1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012063917A (en) * 2010-09-15 2012-03-29 Ntt Docomo Inc Device for evaluating power consumption of application, distribution server and method
JP2016081429A (en) 2014-10-21 2016-05-16 富士通株式会社 Sensing control program and portable terminal device
KR101758267B1 (en) * 2016-03-10 2017-07-17 한국과학기술원 Communication apparatus for predicting power consumption of mobile application, communication system having the same, method of predicting power consumption of mobile application and method of providing predicted power consumption of mobile application

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8538484B2 (en) * 2009-08-14 2013-09-17 Google Inc. Providing a user with feedback regarding power consumption in battery-operated electronic devices

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012063917A (en) * 2010-09-15 2012-03-29 Ntt Docomo Inc Device for evaluating power consumption of application, distribution server and method
JP2016081429A (en) 2014-10-21 2016-05-16 富士通株式会社 Sensing control program and portable terminal device
KR101758267B1 (en) * 2016-03-10 2017-07-17 한국과학기술원 Communication apparatus for predicting power consumption of mobile application, communication system having the same, method of predicting power consumption of mobile application and method of providing predicted power consumption of mobile application

Also Published As

Publication number Publication date
KR20190029298A (en) 2019-03-20

Similar Documents

Publication Publication Date Title
US8079018B2 (en) Test impact feedback system for software developers
US8756586B2 (en) System and method for automated performance testing in a dynamic production environment
US20030177417A1 (en) System and method for remote performance analysis and optimization of computer systems
US10169002B2 (en) Automated and heuristically managed solution to quantify CPU and path length cost of instructions added, changed or removed by a service team
JP2006260542A (en) Determination of actual amount of time a processor consumes in executing code portion
KR20060061759A (en) Automatic validation and calibration of transaction-based performance models
US20140365990A1 (en) Software evaluation device and method
Malavolta et al. A framework for the automatic execution of measurement-based experiments on android devices
CN109359020A (en) Start time test method and device, computer installation and storage medium
US10528456B2 (en) Determining idle testing periods
US20160232366A1 (en) Systems and methods for verification and deployment of applications to programmable devices
Smith Software performance antipatterns in cyber-physical systems
Atonge et al. The development of data collectors in open-source system for energy efficiency assessment
RU2640637C2 (en) Method and server for conducting controlled experiment using prediction of future user behavior
Min et al. PADA: Power-aware development assistant for mobile sensing applications
KR102045892B1 (en) Development assistant apparatus of mobile sensing application, development assistant system having the same, method of assisting development of mobile sensing application using the same
US10928877B2 (en) Communication device for predicting power consumption of mobile application, communication system including same, method of predicting power consumption of mobile application and method of providing predicted power consumption of mobile application, using same
Nikitenko et al. System monitoring-based holistic resource utilization analysis for every user of a large HPC center
US20160209908A1 (en) Cloud-based integrated system for developing and evaluating energy efficient software
EP2972879A1 (en) Method and system for analyzing a trace timeline of computer system activity
Hamzaoui et al. Measurement-based methodology for modelling the energy consumption of mobile devices
JP2715904B2 (en) Computer system performance evaluation device
CN106897387B (en) Service detection method based on action simulation
Danciu et al. Towards Performance Awareness in Java EE Development Environments.
Min et al. Scalable Power Impact Prediction of Mobile Sensing Applications at Pre-Installation Time

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant