Scenario Driven Design for Embedded Systems

From ScenariosWiki

Scenario based design has been used for a long time in different areas, like human-computer interaction or object oriented software engineering. In both these cases, scenarios concretely describe, in an early phase of the development process, the use of a future system. In case of human-computer interaction, the scenarios appear like narrative descriptions of envisioned usage episodes, and in case of object oriented software engineering like a unified modeling language (UML) use-case diagram which enumerate, from functional and timing point of view, all possible user actions and the system reactions that are required to meet a proposed system function. These scenarios are called use-case scenarios.

In the embedded systems area, use-case scenarios are used in both hardware and software design. In these cases, the scenarios focus on the application functional and timing behaviors and on its interaction with the users and environment, not on the resources required by an application to meet its constraints. These scenarios are used as an input during application design for user-centered design approaches.

In this work group, we concentrate on a different type of scenarios, so called application scenarios, which may be derived from the behavior of the application. These scenarios reduce the system cost by exploiting information what can happen at run-time to make better design decisions. While use-case scenarios classify the application's behavior based on the different ways it can be used, application scenarios classify it based on the cost aspects.

The figure on the right depicts a design trajectory using use-case and application scenarios. It starts from a product idea, for which the stakeholders define the product's functionality as use-case scenarios. These scenarios characterize the system from a user perspective and are used in a user-centric development process to design an embedded system that includes both software and hardware components. In order to optimize the design of the system, the detection and usage of application scenarios augments this trajectory (the bottom gray box from the figure). The run-time behavior of the application is classified into several scenarios, where the cost within a scenario is always fairly similar and between scenarios it is fairly different. For each individual scenario, more specific and aggressive design decisions can be made.

The sets of use-case scenarios and application scenarios are not necessarily disjoint, and it is possible that one or more use-case scenarios are merged in one application scenario, a use-case scenario is split into several application scenarios, or that several application scenarios intersect several use-case scenarios.

Example Let us consider that we want to design a small portable MP3 player as a USB stick. At first sight, there are two main use-case scenarios: (i) the player is connected to the computer and music files are transferred between them, and (ii) the player is used to play music. These scenarios can be divided in more detailed use-case scenarios, like, for the second one, we may have the song selection, playing or fast forward scenarios. Let us consider the playing use-case scenario. From the software point of view, this use-case can be split in two different application scenarios: playing songs (i) in mono mode and (ii) in stereo mode. If these scenarios are detected in the application, and the information about them is used during the system design, the system battery lifetime may be increased, as in case of playing in mono mode less computational power is needed, thus a lower supply voltage may be used to meet the timing constraints of the decoding.

A design methodology based on scenarios needs to tackle the following four issues.

• Identification: given the application, how is it classified into scenarios?
• Detection: given a particular run-time situation, to which scenario does it belong?
• Exploitation: given a particular scenario, what can be done to optimize the cost?
• Switching: when and how does the application switch from a scenario to another?

A full overview of application scenario usage in streaming-oriented embedded system design can be found here. For more details about what we are doing, please check our publications.