Servicerobotik Ulm, SeRoNet, RobMoSys

M1lJpeLvESQ

Irrespective of whether you are talking about a device, a piece of software, a service, or whatever else, as a user or customer you need to be able to discover and select the products matching your requirements, make a decision for a product, and connect, configure, operate & use that product in a proper, in an intended and in a safe way.

As a result, you want to get the foreseen and specified behavior of the product in your context. Can you think of the outcome of using that product in your setting before you commit yourself and before you deploy that product in your real-world setting?

The user or customer is in need for information to find out which TV set is the right one for his needs. Basically, he wants to know whether he can use it with a satellite dish, whether he can record a movie while watching another channel, whether the design fits to the furniture style etc.

For this, you need to get access to properties of TV sets in an easy to understand way. You need to know the dimensions and the weight, how to connect it (power, stereo), how to configure it (channel setup, language preferences) and how to properly use it (channel selection, recording). This includes also knowing about what you should not do (cover vents, use it outdoors).

The manufacturer or sales perspective is a different one. How to explain the TV set such that the customer understands whether it fits his / her needs and expectations, finally selects and buys the product, can use it and is satisfied with it? How to clearly outline what are finally the specifications of the product? As a provider, you are responsible for the fulfillment of the named specifications and your customers claim their fulfillment.

This is where datasheets come in!

A datasheet is a document, printed or electronic, that tells you everything you need to know about a part in order to become able to work with it, irrespective of whether that part is a device, a piece of software, a service or whatever else.

A datasheet is a model!

A datasheet addresses different information needs of different kinds of users by different sections following a domain-specific structure. We consider technical specifications, operation manuals, user guides, product safety labels, certificates etc. all as parts of a datasheet. Of course, a datasheet can refer to external documents and can express conformity thereto, in particular to external (de-facto) standards.

A datasheet helps in finding and selecting a part and in making a buying decision. It explains how to connect, configure, operate and use a part. It explicates what are proper, intended and safe ways to do so. It describes how the part behaves under which conditions.

A datasheet takes an external view on the part (block) and its interfaces (ports). It is an abstracted description of the part. It describes internals only as far as you need to know them for properly working with the part.

A datasheet never comprises everything down to the smallest details. It is not about explicating and understanding all the internals of a part. It is not a blueprint for enabling you to produce the part. It is not in conflict with protecting intellectual property related to internals of the part.

Basically, a datasheet contains just that information you need to know in order to make sense out of the part. It comprises just sufficient detail (“need to know”) that allows you to understand the role of that part in a system context.

A datasheet comprises sections with informal information and sections with formalized information.

The informal sections help in gaining attention for a part, advertizing it and explaining it in a broader context and to a broader audience and allow them to discover and find it. They are typically expressed in a way that focuses on the customer and that links to his / her background. They are often about non-technical aspects and express technical aspects in a way that they can be interpreted from within the customer domain without requiring the customer to have a background in the technology domains on which the product is based. They typically serve for a rough pre-selection and are typically not meant as strictly assured properties.

The formalized sections are typically technical specifications and assured properties (an explicit set of features and properties that is satisfied). They are accessible for automatic processing. They can be used with tools to analyze and predict the outcome of using a particular part in a particular configuration in a particular context. They are used for composition and predictability.

It is the responsibility of the product provider to come up with a datasheet such that the custom-oriented (often informal) descriptions and the (often formal) technical specifications are consistently matched and fit together.

You cannot go through all combinations of all parameters with real systems in order to know about all the possible outcomes for the properties of your system and then select the one best fitting your requirements.

You need to be able to answer “what-if” questions with tools which give the answers quickly and which are user-friendly and allow you to end up with an adequate solution (trade-off analysis, multi-criteria-optimization, constraint-based reasoning).

The formalized part of a datasheet helps to think of complex systems before we build them. It helps to answer what-if questions. It helps to find adequate solutions.

A datasheet is a model of a product, a piece of software, a service, or whatever else, (i) with the focus of being able to use the described part, (ii) is not rich enough for synthesis of the described part, (iii) with a focus of enabling you to put the described part into your context, (iv) is rich enough to predict its fit for your context and to your system to understand what you then get in your context.

A datasheet comprises different sections, informal and formalized ones, supports different role-specific views and follows a structure (conforms to a meta-model).

A datasheet gets its semantics (i) by grounding its content to an outside body-of-knowledge (user domain, standards), (ii) by referring to the concrete part for all those aspects not explicated in the datasheet.

A datasheet is key for applying engineering principles in a modern economy with separation of roles, system composition, division of labor, commodity building blocks, protection of intellectual property.