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:

• Roles in the Ecosystem

A very generic but extremely important user story illustrating the full scope of RobMoSys by a single example: Based on model-driven tools, develop and provide composable navigation components with all their explicated properties, variation points, resource requirements etc. (the modeling twin / data sheet). Become able to compose your navigation system out of these readily available commodity building blocks according to your needs and be sure that your needs are being matched, that the properties become traceable etc.

• I, as system builder, just want to become able to compose robotics navigation out of commodity building blocks according to my needs with predictable properties, assured matching with my requirements, free from interference. It is just astonishing that this is not yet possible in robotics. (with MoveBase being exactly an example of 1how it should not be)

RobMoSys achieves a specific level of quality and traceability in building blocks, their composition and the applications.

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 xxx). A data sheet contains everything you need to know to become able to use that 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 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 that 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.

A hardware device is broken and the identical device is not available anymore (deprecated, discontinued, only next version available). As a system builder,

• I want to check whether all my relevant system level properties and constraints are matched when I use the new device.
• I also want to know how I need to configure it for that.

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

• As a system builder, when I remove a software component from a system, I want to know which constraints define the now white spot in my design in order to fill in another one with the proper configuration to again match the system level properties.

Example:

• From laser-based localization to visual localization
• Replacing a 6 DOF manipulator with a 5 DOF manipulator

I want to be able to predict selected properties of the composition of various software components given their individual properties, their configurations, their composition. For example, 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, e.g.

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

• 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
• at deployment time (system builder), reservation based resource management should be tool supported

As system builder, I want my system (e.g. navigation system on a mobile robot) to work exactly the same way again 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

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

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.

Separation of roles (in particular, 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.

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.

There are analysis tools in related domains not yet accessible to robotics as they are complex to use. I would like to have support from 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. These tools should be attached to robotics via dedicated model transformations without requiring me to get into them.

• Reusable and composable task blocks which express knowledge about how to execute tasks (action plot) and what are good ways to execute tasks (qualities).
• Management of 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.
• As safety engineer, I model constraints for particular applications and environments.
• As system builder, I want to be able to import these 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.)

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).