Skip to content
This repository has been archived by the owner on Jun 16, 2024. It is now read-only.

Latest commit

 

History

History
389 lines (258 loc) · 13.2 KB

OTRL.md

File metadata and controls

389 lines (258 loc) · 13.2 KB
Raw

title: Technology Readiness Levels for Open Source Hardware

Notes

  • requirements:
    • rapidly assess suitibility of technology for a certain use case & operation environment (& easily monitor progress made by the project in this regard)
    • fast & intuitive assessment → clear criteria, least possible testing / data akquisition possible
    • Compare very diverse technologies (as stated in this paper) → high abstraction
  • derived from EU-H2020 Annex G
    • titles have been copied (partly shortened)
    • …and interpreted for the context of OSH
    • …considering ESA's handbook (ref) and NASA's definitions (ref)

Principle

Based on a known and widely used concept:

Technology readiness levels (TRLs) are a method for estimating the maturity of technologies ...

from Wikipedia - Technology Readiness Level

[NASA's] TRLs […] provide useful insights into two key contributors to readiness:

  1. degree of functionality provided
  2. fidelity of the environment (to the intended operational environment) in which this functionality has been demonstrated

(ref)

Regardless of the criticism, the TRL approach is chosen as it is well tested and simpler, thus easier to use. That stated, the authors found TRL more suitable for a stable, decentralised application in an open source environment than proposed alternatives (as e.g. ref).

It is a special property of open source hardware that the technology is available for anyone. Specifically, it is the technical documentation that enables entities to study/use, make, modify and distribute the technology (ref: DIN SPEC 3105-1). However, technology readiness can be independent from the state of the documentation. Hence, two scales are introduced:

  1. Technology Readiness Levels for the context of OSH (OTRL)
  2. Documentation Readiness Levels for the context of OSH (ODRL)

Both will be provided as text and RDF document to ensure equally human and machine readability.

Concept

OTRL

Resources:

OTRL Stage Goal
OTRL 1 Ideation Product idea, needs and initial specifications are defined
OTRL 2 Conception Mature product concept has been formulated
OTRL 3 Development Product model is developed
OTRL 4 Prototyping and testing Full functional prototype is built and tested
OTRL 5 Manufacturing development Fairly reliable processes identified and characterised
OTRL 6 Product qualification Certificate marking conformity assessment or comparable

basically:

  1. defining requirements
  2. conceptionalise the solution
  3. translate solution conecpt into a physical hardware solution
  4. design a product that a) reliably covers core features and b) can be built, modified and operated by non-contrbutors
  5. finish all relevant tests for CE certification

ODRL

It is the complete technical documentation, published under a free/open license, that differentiates open source hardware from proprietary hardware.

This "completeness" has been divided into the following 5 levels as shown in table @tbl:odrl-overview. A detailled description of these levels can be found in the following chapters.

ODRL Name Goal
ODRL 1 Documentation process commenced Published information under free open source licence
ODRL 2 Collaborative documentation in progress Provision of documentation files and in editable formats enabling collaboration development
ODRL 3 Full documentation published Complete documentation as per DIN SPEC 3105-1
ODRL 3* Full documentation published & audited Public evidence of documentation maturity
ODRL 4 Full documentation for product qualification Product qualification documents published enabling decentralised commercial distribution

: Overview on ODRLs {#tbl:odrl-overview}

ODRL 1

documentation started & accessible

IN SHORT: By OSHWA-compliant licensing terms, free rights of any use are granted to the general public,
BUT not executable due to missing files and information;

ENABLING the (legal) use of published information as free/open source material.

THIS INCLUDES:

  • a free/open license compliant to the OSHWA definition;
  • that all legal information (author(s), title, legal code of the license) is available and
  • distributed with an unambiguous reference to the specific published documentation (e.g. by the use of git tags for releases).

EXIT CRITERIUM:

  • design files published in editable file format (e.g. STEP (or better: native CAD files) instead of PDF drawings)

ODRL 2

documentation under collaborative development

IN SHORT: Source files are published in editable formats,
BUT documentation is yet under development and non-native file formats may be chosen;

ENABLING the practical execution of free rights of any use and by that a collaborative development of the documentation.

COMMENT:

  • It is recommended, that information shall be provided in such a way that allows for 1) lossless information distribution (compared to the original development) for modification, 2) without raising the need of proprietary software to study the information;
    • specifically for 3D modelling this means in practice that a CAD file shall be distributed 1) in its native file format 2) alongside with an exported copy in an exchange format (e.g. STEP).

EXIT CRITERIUM:

  • stable documentation release published

ODRL 3

full documentation

IN SHORT: Documentation has been completed and deemed fully compliant with DIN SPEC 3105-1,
BUT only by self-assessment by maintainers of the project.

ENABLING the full exploitation of the piece of open source hardware, theoretically.

THIS INCLUDES:

  • a release of the final documentation that is deemed stable.

EXIT CRITERIUM:

  • attestation from a confirmity assessment body according to DIN SPEC 3105-2 (or equivalent proofs of conformity)

ODRL 3*

audited documentation

IN SHORT: Documentation has been attested to be fully compliant with DIN SPEC 3105-1 in a community-based process according to DIN SPEC 3105-2,
BUT yet documentation relevant for CE certification is missing;

ENABLING a trustworthy full exploitation of the piece of open source hardware.

THIS INCLUDES:

  • an attestation from a confirmity assessment body according to DIN SPEC 3105-2 (or equivalent proofs of conformity as e.g. through an OSHWA certification, a RYF certification or a scientific publication including the technical documentation).

EXIT CRITERIUM:

  • CE documentation published

ODRL 4

audited documentation including CE certification documents

IN SHORT: Documentation has been attested following DIN SPEC 3105-2 and includes all documentation relevant for CE certification

ENABLING decentralised commercial distribution of the piece of open source hardware.

THIS INCLUDES:

  • xxx.