Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

State

INCUBATION

Charter reviewed by DEG and TST,  accepted by TST Mon, June 3rd 2024. No board veto.


Table of Contents
excludeState
stylenone


Type & Scope

This is a  project operating under the Data Expert Group. The aim is to create an OSS implementation of the IEEE 1722 (IEEE Standard for a Transport Protocol for Time-Sensitive Applications in Bridged Local Area Networks) targeting Linux platforms. 

Planned Activities and Goals

Scope

An OSS implementation of the IEEE 1722 standard that runs on Linux in user space

Fit to COVESA

IEEE1722 (AVTP) is a very "automotive" technology to transport or tunnel various data formats in a vehicle. Compared to high level protocols such as SOME-IP or DDS, 1722 is a layer-2 protocol, that emphasizes simplicity and performance.  For certain applications it can even be implemented "in hardware" without the need for a microcontroller running a full stack.

Gap

The proposed project will greatly change and extend the scope of an existing project https://github.com/Avnu/libavtp that is not active anymore, and merely focusses on the audio/video ports, but leaves out automotive relevant things such as CAN. The goal is to make this transparent by forking form the original repository.

This is allowed, as the original is licenses under a 3-clause BSD license.

The goal is to keep the license as 3-clause BSD, as it is very permissive. (Except making it easy to apply it commercially, it also fully compatible with Apache-2.0 license used by many "new" SDV projects or MPL license used core COVESA projects)

...

What is the purpose of the project?

Open1722 is intended to be an open source userspace user space implementation of the IEEE 1722 standard that defines the Audio/Video Transport Protocol (AVTP).
Despite its name, the protocol covers the transport of data beyond audio and video formats, such as automotive fieldbus technologies like CAN, LIN, etc. over a layer 2 Ethernet network.
This protocol is gaining traction in the automotive domain because, compared to higher-level protocols such as SOME/IP or DDS, it is well suited for transporting data to and from extremely resource-constrained devices, or even for full hardware implementation. 

Use cases include tunneling of fieldbuses over an Ethernet network across domains/zones, remote control of deeply embedded sensors/actuators etc. In fact, Open1722 could also be used in combination with Vehicle Signal Specification (VSS) for mapping VSS datapoints to interactions with remote peripheral devices using IEEE 1722 messages, thus, enabling use cases where cloud applications interact with deeply embedded devices using VSS APIs.

What is the intended outcome/deliverable of the project?

Open1722 intends to be a full implementation of the IEEE 1722-2016 standard, though we will start with features/data formats which are interesting from an automotive standpoint (e.g. support for the AVTP Control Formats (ACF) which includes serialization of CAN and LIN).
Eventually the implementation maybe updated to cover the newer releases revisions of the standard as and when IEEE publishes the same.

How will the project be licensed?

The project will be forked from AVNU/libavtp which is licensed under 3-clause BSD.
Open1722 will retain the license and continue to make the implementation available under 3-clause BSD.

Who are the maintainers/leads?

Naresh Nayak - Robert Bosch GmbH
Adriaan Niess - Robert Bosch GmbH

What other companies/contributors are likely to be involved?

Open1722 will strive to serve as a reference implementation for IEEE 1722 for the adopters who could then explore this transport protocol by integrating it in their products/demos. 

The proposed project will greatly change and extend the scope of the existing AVNU project libavtp, that is not active anymore, and merely focusses on the audio/video ports leaving out automotive relevant things such as CAN. The goal is to make this transparent by forking from the original repository.

This is allowed, as the original is licensed under a 3-clause BSD license.

Fit to COVESA

IEEE1722 (AVTP) is a very "automotive" technology to transport or tunnel various data formats in a vehicle. Compared to high level protocols such as SOME-IP or DDS, 1722 is a layer-2 protocol, that emphasizes simplicity and performance.  For certain applications it can even be implemented "in hardware" without the need for a microcontroller running a full stack. It is an important building block in SDVs that currently has no comprehensive implementation, neither at COVESA nor at other SDV-related organizations.


Organization & Working mode

Deliverables

The main deliverable of the project will be source code available in an Open1722 repository under the COVESA Github organization.
Reference applications sending and receiving IEEE 1722 messages will also be a part of this repositoryBosch & ETAS are expected to kickstart the development and initial maintenance.

What will be the way of working for the project?

Open1722 will be developed following the OSS best practices.
Contributions are welcome from the automotive community via pull requests.  
These Project maintainers will ensure these will be reviewed on a timely basis before being merged in the codebase.  

License

The project will be forked from AVNU/libavtp which is licensed under 3-clause BSD. The goal is to keep the license as 3-clause BSD, as it is very permissive. (Except making it easy to apply it commercially, it also fully compatible with Apache-2.0 license used by many "new" SDV projects or MPL license used core COVESA projects)

Initial partners

Bosch & ETAS are expected to kickstart the development and initial maintenance.
Other companies are of course also welcome to join in the efforts. 

Maintainers

Initial maintainers will be 

  • Naresh Nayak - Robert Bosch GmbH
  • Adriaan Niess - Robert Bosch GmbH

The project is responsible to nominate maintainers, that will act as primary contacts inside and outside of COVESA and ensure COVESA regulations and code of conduct are adhered to.
If the project loses all its maintainers, COVESA TST together in alignment with the board may:

  1. Try to appoint new maintainers
  2. Opt to officially retire and archive this project

Project retirement

If in future it becomes necessary to retire the project, COVESA will communicate this clearly in the project repositories, but will keep to make the generated code and artifacts, so the work can be picked up and restarted again in or outside of COVESA.

Reporting

The goal is to interact with the larger COVESA community and present results and work during events such as the AMMs.
As that might not always be possible, the project will at least provide a 1-page report to update  TST and board at very AMM. 

Sustainability

The aims is to gather interested parties and keep this project running and relevant for a long time.
For the initial period we want to point out that the initial partners are supported by the European HAL4SDV project in this endeavor.


View file
name1722_COVESA_Presentation.pdf
height250