How to Combine Embedded Systems and Cloud Computing?

Embedded systems are everywhere. Yet, many of these systems are islands in an age where more and more systems are being connected to the Internet. The ability to connect to the Internet can be taken advantage by resources cloud computing can offer. A recently finished thesis conducted in the Software Systems Engineering Research Group at the University of Helsinki presents what cloud enhanced embedded systems are and what their benefits, risks, typical implementation methods, and platforms are.

The study addresses the questions

  • What use cases are there for combining cloud and embedded systems?
  • What kind of experience or empirical evidence exists for integrating cloud into embedded systems?
  • How are cloud enhanced embedded systems classified?
  • What are the benefits of cloud and embedded system integration seen by researchers?
  • What are the risks and challenges of cloud and embedded system integra- tion seen by researchers?

What are the prerequisites for integration of cloud into embedded systems?
How is the integration of cloud into embedded system typically done?
What architectures, platforms and hardware are used in cloud enhanced embedded systems?
The study shows that the interest from academia and practice in cloud enhanced embedded systems has been growing significantly in recent years. The most prevalent research area is wireless sensor networks followed by the more recent research area Internet of things. Most of the technology is available for implementing cloud enhanced embedded systems but comprehensive development tools such as frameworks or middle wares are scarce. Cloud enhanced embedded systems will also be key for the Industrial Internet (sometimes also referred to as Industry 4.0 / Industie 4.0)

Results of the study indicate that existing embedded systems and other non-computing devices would benefit from connectivity and cloud resources. This enables the development of new applications for consumers and industry that would not be possible without cloud resources.

Perceived benefits of cloud integration to embedded systems are

  • Remote Monitoring Ability
  • Extended Data Storage
  • Benefits from Distribution
  • Pervasiveness
  • Offloading (Data, processing)
  • Ad-hoc communication
  • Remote Management
  • Added Functionality
  • New Application Possibilities
  • Web services
  • Mobility

The academic literature is full of use cases for cloud enhanced embedded systems and model implementations. However, the actual integration process as well as specific engineering techniques are rarely explained or scrutinized. Currently, the typical integration process is very custom to the application. There are few examples of efforts to create specific development tools, more transparent protocols, and open hardware to support the development of ecosystems for cloud enhanced embedded systems. Read the study here.

Related article:

  • [PDF] [DOI] Nilay Oza, Jürgen Münch, Juan Garbajosa, Agustin Yague, Eloy Gonzalez Ortega. Identifying Potential Risks and Benefits of Using Cloud in Distributed Software Development. In Proceedings of the 14th International Conference on Product-Focused Software Development and Process Improvement, June 2013. Paphos, Cyphrus, June 12-14, 2013
    [Bibtex] [doi] [url] [pdf]
    @inproceedings{OMGYG13,
    author = {Nilay Oza, Jürgen Münch, Juan Garbajosa, Agustin Yague, Eloy Gonzalez Ortega}, 
    title = {Identifying Potential Risks and Benefits of Using Cloud in Distributed Software Development}, 
    booktitle= {Proceedings of the 14th International Conference on Product-Focused Software Development and Process Improvement}, 
    year = {2013},
    month = {June},
    note = {Paphos, Cyphrus, June 12-14, 2013},
    url = {http://link.springer.com/chapter/10.1007%2F978-3-642-39259-7_19},
    doi =  {10.1007/978-3-642-39259-7_19}
    }

How to Find out Which Features to Implement in Popular Smartphone Apps?

In the world of smartphone applications, there is a rich set of user feedback and feature suggestions which are updated continuously. Especially for smaller development teams, prioritizing these requests is of utmost importance. The prioritization is usually done based on techniques which rely on methods that are built upon predictions and customer interviews such as “Would you buy that feature?”. However, predictions can be wrong and customer interviews suffer from contextual biases.

We developed an approach that allows us to find out about the real business value of a feature. The approach is based on mock purchases and allows product managers and developers to depict the real business value of a feature without having to implement it. Hence, the approach allows feature prioritization based on facts rather than on predictions. The rationale behind the approach is to eliminate contextual biases. On top of that, the approach allows us to experiment with the feature pricing.

approach

Figure 1. Approach.

Figure 1 depicts six elements of the approach:

Product Backlog: Each user is assigned only one of the features from the backlog that are to be tested. Thereby, potential contextual biases can be reduced to a minimum.
Description Page: For each feature, a custom description page is created which describes the feature and contains a button to load the feature’s price.
Purchase Page: After loading the price, the amount is displayed on the page and a purchase button appears.
Acknowledgement Page: After purchasing, the user receives an acknowledgement about the feature not having been implemented yet. Moreover, the user is then asked whether he or she likes, dislikes, or very much dislikes the approach. On top of that, he or she can provide a custom message in case he or she needs the feature urgently or wants to complain.
Questionnaire Page: In case the user cancels the purchase (i.e. wants to move away from the page after having loaded the price), he or she is asked why he or she did so. Users can choose that they are not interested in the feature, it is too expensive, they were disappointed by other in-app purchases, or they do not spend money on apps. They can also provide a custom message.

The study was implemented in an app called Track My Life which is used by Nokia CEO Stephen Elop and the Finnish Minister for European Affairs, Alexander Stubb amongst others. The app is a GPS Tracker that automatically collects the users’ location information in the background and analyses the data upon opening the app. Thereby, it can answer questions such as “How much time do I spend at home, work, and on my way to work?”. On top of that, it provides statistics such as how many kilometers the user travels per day, week, and month, and which places he or she spends most of his or her time at.

Moreover, the app leverages user feedback by providing several mechanisms e.g a Zendesk and Jira client to provide feedback to the developer.

The study started on April 5, 2013 and ended on April 23, 2013. Prior to that, the implementation of the app in both the iOS and Windows Phone version was done. The implementation took about 1.5 days per platform due to specialities such as the possibility to enable and disable the study remotely and converting feature prices to the users’ local currencies in price intervals which correspond to their smartphone operating system’s pricing intervals (i.e. convert 1€ to flat 70 rupee rather than to 71.54 rupees). Figure 2 represents the implementation of the approach on iOS (left) and Windows Phone (right).

Implementation

Figure 2. Implementation on iOS and Windows Phone.

Finding the Right Features to Implement

Figure 3 depicts the number of purchases that were made as well as the hypothetical revenue attached to those. Each of the six columns represents one feature at a given price tag. In total, there were two features being investigated, each of those at the price tags EUR 1, EUR 3, and EUR 5. As an example, SSF represents feature one and the number 3 represents that the base price (i.e. the price that was converted into the users’ currencies) was EUR 3.

revenue

Figure 3: Number of purchases and revenue.

As anticipated, figure 3 depicts a correlation between the number of purchases and the price of a feature. Moreover, it allows us to compare the two features and also allows us to make judgements about the feature pricing. For instance, EUR 5 for the HF feature yields a lower total revenue than EUR 3. In contrast to that, the maximum revenue for SSF seems to be at an even higher price tag than EUR 5. Moreover, the revenue created with SSF is higher than HF.

tooexpensive

Figure 4: Number of users who said that they did not buy the feature because it is too expensive.

Figure 4 shows the number of users who regarded the feature as too expensive when surveyed about why they cancelled the purchase (i.e. tried to navigate back from the feature’s description page after loading the price). It underlines the point that there is a correlation between a feature’s price and the number of purchases and also that fewer users are willing to pay for the feature HF at a price tag of EUR 5 than for SSF at the same price.

14% of the users were unsatisfied (i.e. selected I dislike the approach) or very unsatisfied (i.e. selected I am very annoyed by the approach). However, the wide majority of users understood the purpose of the experiment.

We showed that the approach allows us to find out about the real return of a feature and allows us to find the ideal price of a feature.

The study is described in the following article and will be presented at the Lean Enterprise Software and Systems Conference in Galway, Ireland (December 1-4, 2013). The reference for the article is the following:

  • [PDF] [DOI] Alexander-Derek Rein, Jürgen Münch. Feature Prioritization Based on Mock Purchase: A Mobile Case Study. In Proceedings of the Lean Enterprise Software and Systems Conference (LESS 2013, Galway, Ireland, December 1-4), volume 167 of LNBIP, pages 165-179. Springer Berlin Heidelberg, 2013.
    [Bibtex] [doi] [url] [pdf]
    @inproceedings{LESS2013b,
      author    = {Alexander-Derek Rein, Jürgen Münch},
      title     = {Feature Prioritization Based on Mock Purchase: A Mobile Case Study},
      booktitle = {Proceedings of the Lean Enterprise Software and Systems Conference (LESS 2013, Galway, Ireland, December 1-4)},
      publisher = {Springer Berlin Heidelberg},
    series = {LNBIP},
    volume = {167},
    pages = {165-179},
      year      = {2013},
    doi = {10.1007/978-3-642-44930-7_11},
    url = {http://link.springer.com/chapter/10.1007/978-3-642-44930-7_11}
    }