User Tools

Site Tools


Technical User Stories

The following user-stories provide more detailed examples of the primary user-stories and the user-stories presented at the ERF 2017. The user-stories are supposed to guide RobMoSys consortium to provide the structures and the open call third party partners to apply.

User-stories are described in the As user, I want-style:

  • As a (role), I want (goal, objective, wish), so that (benefit)
  • As a (role), I can (perform some action), so that (some goal is achieved)

Some user-stories are described in context of a specific ecosystem participant or role. Some are not described in a specific context and can apply to multiple roles. For example what is of interest to an integrator can be of interest to a supplier since the integrator might also supply a system (see system-of-system).

See also:

Composable commodities for robot navigation with traceable and assured properties

Based on model driven tools, RobMoSys enables development of composable navigation components, with all their explicated properties, variation points, resource requirements etc. (the modeling twin / data sheet).

As system builder,

  • I want to be able to compose robotics navigation components from commodity building blocks according to my needs (predictable properties, matching system requirements assured, free from interference) without having to develop such components from scratch every time, while ensuring my system requirements are matched and their properties are traceable.

Description of building blocks via model-based data sheets

RobMoSys achieves a specific level of quality and traceability in building blocks, their composition and the applications. A data sheet is a document that contains everything you need to know to be able to use a software component in a proper way (interface between the component and its environment) while protecting intellectual property. It contains information about the internals of the software component only as long as this is needed for a proper use.

as a component supplier

  • I want my component to become part of as many systems as possible to ensure return-of-investment for development costs and to make profit.
  • I need to offer my software component (building block) such that others can easily decide whether it fits their needs and how they can use it.
  • I want to offer my software component with a data sheet in form of a digital model (see Modeling Twin).

as a system builder

  • I want to select from available components the one which best fits my requirements and expectations (provided quality, required resources, offered configurability, price and licensing, etc.)
  • I want to check via the data sheet (in form of a digital model) whether a building block with all its strings attached fits into my system given the constraints of my system and given the variation points of the building block. Thereto, I want to be able to import it into my system design to perform e.g. a what-if analysis etc.
  • I want to extract from my system design the specification of a missing building block such that someone else can apply for providing a tailored software component according to my needs
  • I want to use components as grey-box, use them “as-is” and only adjust them within the variation points expressed in the data-sheet without the need to examine or modify source code.

Replacement of component(s)

Consider the scenario in which a hardware device is broken and the identical device is not available anymore (deprecated, discontinued, only next version available). For example: when replacing laser-based localization with visual localization hardware, when replacing a 6 DOF manipulator with a 5 DOF manipulator, etc.

As a system builder,

  • I want to check whether all my relevant system-level properties and constraints are matched when replacing an old device with a new one, while knowing how to configure the new HW.
  • When removing a software component from a system, I want to know which constraints define the now empty spot in my design in order to fill it with the proper configuration to match again the system-level properties.

Note: the same holds true for software components where a software library used is not available anymore with updates of other libraries etc.

Composition of components

As a System builder,

  • I want to predict selected properties of the composition of various software components given their individual properties, their configurations, their composition. (I want to know about the required resources, whether there are bottlenecks somewhere, whether there are no unnecessarily high update rates without consumers requiring them etc.)
  • I want to know about the consistency of the overall settings in order to increase the trust into the system. I want to know that critical paths are transformed from design-time into run-time monitors and sanity checks.

Quality of Service

As a system builder,

  • I would like to know whether the amount of resources and the achieved performance (in general, quality of task achievement) is adequate.
  • I want to know what kind of impact a decrease in resource assignment has on the performance of the functionalities of the robot.
  • I want to make sure that properties are traceable through the system and are managed through the development and composition steps. For example:
    1. qualities at service ports of components are linked with component configurations which are linked with configurations of the execution container and the underlying OS and middleware
    2. at deployment time (system builder), reservation based resource management should be tool supported

Determinism, e.g. for robot navigation

As system builder,

  • I want my system (e.g. navigation system on a mobile robot) to work exactly the same way when I change the platform (e.g. change the mobile base or the laser ranger or the computing platform in a mobile robot).
  • I want to know that the intended functional dependencies and intended processing chains are finally realized within my system composition
  • I want to know that relevant functional dependencies are still valid even after replacing one of my onboard computers by a different one

Free from hidden interference

As a system builder,

  • When extending a system, I want to know that I do not interfere with the already setup components, allocated resource shares etc.
  • I want to be sure that deploying further components onto my system is free from hidden interference or hidden side-effects.

Management of Non-Functional Properties

Separation of roles between component providers (driven by technology) and system builders (driven by the application domain) is considered a basic prerequisite towards the next level of market maturity for software in robotics, and thus towards a software business ecosystem. Support for the system builder is needed in order to know about the properties of resulting systems instead of wondering whether they match the requirements or whether they are resource-adequate etc.

As system builder,

  • I want to be able to adhere to functional and, in particular, to non-functional properties when composing software components.
  • I want to re-use software components as black (gray) boxes with explicated variation points such that application-specific system-level attributes can be matched without going into the internals of the building blocks.
  • I want to be able to work on explicated system level properties: allow to design system properties such as end-to-end latencies and explicit data-propagation semantics during system composition without breaking component encapsulation.
  • I want to be able to match / check / validate / guarantee required properties via proper configurations of variation points, via sound deployments etc.

Gap between design-time assumptions and run-time situation

When a system is deployed, design-time assumptions might not hold. For many systems it is difficult to know when the system fails during operation. As a system builder,

  • I want to generate sanity checks, monitors and watchdogs from my design-time models to be able to detect unwanted behavior and to detect operation outside of specified ranges.

System analysis tools

There are analysis tools in related domains not yet accessible to robotics as they are complex to use. As a system builder,

  • I would like to have support regarding these tools during the design of components, their selection and composition etc.
  • I want to better address what-if questions, to perform trade-off analysis etc.
  • I want to have access to analysis tools These tools should be attached to robotics via dedicated model transformations without requiring me to get into them.

Task modeling for task-oriented robot programming

As a system builder,

  • I want reusable and composable task blocks which express knowledge about how to execute tasks (action plot) and what are good ways to execute tasks (qualities).
  • I want to manage the constraints such that composition for parallel and nested execution is free of conflicts and that open variation points can be bound at run-time according to the given situation ways to link generic task descriptions (with all their constraints and resource requirements) with software components (with all their configurations etc.)


As safety engineer,

  • I want to model limits for critical properties like the maximum speed when carrying around a hot coffee, when maneuvering in a crowded environment, the maximum speed dependent on visibility ranges etc.
  • I model constraints for particular applications and environments.

As a system builder,

  • I want to import safety constraints such that tools help me to ensure design-time consistency and run-time conformance with them (via generated hard-coded limits, via monitors, via sanity checks etc.)

NOTE: It is important to highlight what we are trying to say about system safety (not necessarily to prove), because systems are safe in a particular context under a particular set of assumptions (e.g. by run-time monitors etc.). The focus is possibly shifted from fail-safe to safe-operational, which may include some liveness in it. It is about efficient falsification (the following things cannot happen) rather than costly verification (it always behaves only like that).

general_principles:user_stories · Last modified: 2019/05/20 10:47