Presented to the TAC: 04/17/2024

Subgroup reviewed on:

Subgroup readout to the TAC:

Project Proposal - Project Introduction:

Required Information

Responses (Please list N/A if not applicable)

Name of Project

OpenTDX - Open Transport Data eXchange

Project Description (what it does, why it is valuable, origin and history)

OpenTDX is a cloud and edge cloud platform to exchange and distribute data in real-time between users in a certain geography. One use case is V2X (Vehicle to anything communication), where data between road users (like cars) and between road infrastructure (e.g. traffic lights) and road users is anonymously exchanged with each other

Statement on alignment with Foundation Mission Statement

We agree with the foundation's mission statement.

High level assessment of project synergy with existing projects under LF Edge, including how the project compliments/overlaps with existing projects, and potential ways to harmonize over time. Responses may be included both here and/or in accompanying documentation. 

OpenTDX will investigate synergies with other LF Edge projects, like Akraino for leveraging infrastructure and application blueprints. Beside, projects like Fedge, ...

Link to current Code of Conduct

We will adopt LF Edge's Code of Conduct.

2 TAC Sponsors, if identified (Sponsors help mentor projects) - See full definition on Project Stages: Definitions and Expectations

Tina Tsou
Joe Pearson (lbc.)

Project license

Mozilla Public License, Version 2.0

Source control (GitHub by default)

https://github.com/opentdx

Issue tracker (GitHub by default)

https://github.com/opentdx/[component]/issues

External dependencies (including licenses)

Apache 2.0

EPL 1.0, 2.0

MIT,

... full list with dependencies will be updated based on final source code

Release methodology and mechanics

GitHub Releases

Names of initial committers, if different from those submitting proposal

Guido Gehlen 

NATALIA GOROKHOVA 

Nuno Goncalo Castro 

Omar Abaza 

Marius Budu 

Current number of code contributors to proposed project5
Current number of organizations contributing to proposed project4-6 tbc.
Briefly describe the project's leadership team and decision-making process
List of project's official communication channels (slack, irc, mailing lists)Slack and mailing list (tbd. after name has been finalized)
Link to project's websitehttps://step.vodafone.com

Links to social media accounts

N/A
Existing financial sponsorshipVodafone Business
Infrastructure needs or requests (to include GitHub/Gerrit, CI/CD, Jenkins, Nexus, JIRA, other ...)SCM (Gitlab), CI/CD (Jenkins), Artifact Repo (Nexus), Code Scanning (Sonarqube), Jira
Currently Supported ArchitectureCloud, Kubernetes, OpenShift
Planned Architecture SupportCloud, Kubernetes, OpenShift
Project logo in svg format (see https://github.com/lf-edge/lfedge-landscape#logos for guidelines)

tbd. after name is fixed

Trademark statusTrademark will need to be pursed by the Linux Foundation upon project proposal acceptance
Does the project have a Core Infrastructure Initiative security best practices badge? (See: https://bestpractices.coreinfrastructure.org)No
Any additional information the TAC and Board should take into consideration when reviewing your proposal?

Project Proposal - Mapping Criteria and Data:

Stage 1: At Large Projects (formerly 'Sandbox')

Criteria

Data

2 TAC Sponsors, if identified (Sponsors help mentor projects) - See full definition on Project Stages: Definitions and Expectations


A presentation at an upcoming meeting of the TAC, in accordance with the project proposal requirements


The typical IP Policy for Projects under the LF Edge Foundation is Apache 2.0 for Code Contributions, Developer Certificate of Origin (DCO) for new inbound contributions, and Creative Commons Attribution 4.0 International License for Documentation. Projects under outside licenses may still submit for consideration, subject to review/approval of the TAC and Board.


Upon acceptance, At Large projects must list their status prominently on website/readme



*** For existing Projects requesting Stage 2 or Stage 3 consideration, please update the above with the Stage 2 or Stage 3 Mapping criteria, available at Project Stages Mapping: Criteria and Data




Project Proposal - Taxonomy Data:

Functions (Provide, Consume, Facilitate, or N/A; Add context as needed)

Functions

(Provide, Consume, Facilitate, or N/A; Add context as needed)

APIsProvide
(Provide API for publishing and Redis API for configuration)
Cloud ConnectivityConsume
Container Runtime & OrchestrationConsume
Data GovernanceN/A
Data ModelsN/A
Device ConnectivityProvide, Consume, Facilitate
Filters/Pre-processingProvide, Facilitate
LoggingProvide
Management UIN/A
Messaging & EventsProvide, Consume, Facilitate
Notifications & Alerts

Provide

(metrics only)

SecurityN/A
Storage

N/A

Deployment & Industry Verticals (Support, Possible, N/A; Add context as needed)

Deployment Type

(Support, Possible, N/A; Add context as needed)

Customer Devices (Edge Nodes)N/A
Customer Premises (DC and Edge Gateways)N/A
Telco Network Edge (MEC and Far-MEC)N/A
Telco CO & RegionalN/A
Cloud Edge & CDNsN/A
Public CloudSupport
Private CloudSupport

Deployment & Industry Verticals (✔ or X; Add context as needed)

Directly applicable Industry/Verticals use cases

(✔ or X; Add context as needed)

Automotive / Connected Car

ChemicalsX
Facilities / Building automationX
Consumer

Manufacturing

Metal & MiningX
Oil & GasX
PharmaX
Health CareX
Power & UtilitiesX
Pulp & PaperX
Telco OperatorsX
Telco/Communications Service Provider (Network Equipment Provider)X
Transportation (asset tracking)

Supply Chain

Preventative MaintenanceX
Water Utilities

Security / Surveillance

Retail / Commerce (physical point of sale with customers)

Other - Please add if not listed above (please notify TAC-subgroup@lists.lfedge.org when you add one)Drone management, BVLOS

Deployments (static v dynamic, connectivity, physical placement) - (✔ or X; Add context as needed)

Use Cases

(✔ or X; Add context as needed)

Gateways (to Cloud, to other placements)

NFV InfrastructureN/A
Stationary during their entire usable life / Fixed placement edge constellations / Assume you always have connectivity and you don't need to store & forward.N/A
Stationary during active periods, but nomadic between activations (e.g., fixed access) / Not always assumed to have connectivity. Don't expect to store & forward.N/A
Mobile within a constrained and well-defined space (e.g., in a factory) / Expect to have intermittent connectivity and store & forward.N/A
Fully mobile (To include: Wearables and Connected Vehicles) / Bursts of connectivity and always store & forward.N/A

Compute Stack Layers (architecture classification) - (Provide, Require, or N/A; Add context as needed)

Compute Stack Layers

(Provide, Require, or N/A; Add context as needed)

APIsProvide
ApplicationsN/A
FirmwareN/A
HardwareN/A
OrchestrationRequired
(for containers)
OSRequired
VM/ContainersRequired

Cloud Stack Layers (architecture classification) - (Provide, Require, or N/A; Add context as needed)

Cloud Stack Layers

(Provide, Require, or N/A; Add context as needed)

ApplicationsProvide
Configuration (drive)Provide
Content (management system)N/A
IaaSRequire
PaaSRequire
Physical InfrastructureN/A
SaaSN/A


  • No labels