Problem Statement
Historically, projects within the Eclipse Software Defined Vehicle (SDV) Working Group have independently developed their own unique Build & Tooling Environment.This fragmented approach leads to redundant development efforts and "double work," as projects solve similar toolchain and infrastructure challenges in isolation. Furthermore, the lack of build system harmonization creates significant barriers to the joint integration of multiple components, hindering the creation of a cohesive ecosystem.
In response to feedback from the Eclipse SDV Community and the Technical Advisory Committee (TAC), specifically regarding the need for a cohesive view of ecosystem architecture and standardized CI/CD workflow and toolchain, this project is established to centralize these non-differentiating efforts.
Problem Boundaries
This problem focuses on the following key domains:
- Build and Dependency Management
- Environment Management & Tool Provisioning
- Task Runner and Automation
- Development Environment & Enablement
Eclipse SDV Hephaestus centralizes and standardizes build, tooling, and development environments across Eclipse SDV projects to reduce duplication, enable seamless integration and open-source development workflows.
In Scope
- Bazel-based build and dependency management as the harmonized build system, enabling joint integration of multiple Eclipse SDV components
- Other build and dependency management systems e.g. Cargo should be supported
- Doc-as-Code via Sphinx-Needs, establishing a digital thread linking requirements to technical specifications and test execution results
- Using the Eclipse Common Build Infrastructure
- Pilot adoption with Eclipse S-CORE, Eclipse OpenSOVD, and Eclipse Automotive API Framework
- SIL KIT (Eclipse OpenXilEnv) as a candidate for tool integration.
- Qualification process compliant with ASPICE and ISO 26262, preparation and tooling support only
- Automotive Edge but exploring potential synergies between edge and cloud
Out of Scope
- Actual Safety Certification (such as receiving a final product certificate) and the management of associated liability are excluded, because this is considered as a part of a business model or private agreement between contractual partners
- Mandatory integration of commercial or closed-source tools. These remain optional via well-defined plugin interfaces
- Replacing project-specific domain logic
Eclipse SDV Hephaestus ensures low efforts for contributors to participate in a Eclipse SDV project, the implementation is based on open source tools. The starting point for this project is the Eclipse S-CORE toolchain, which will be reviewed to determine how it can be made ready for use by other projects within Eclipse SDV Working Group. To ensure an qualification process compliant to ASPICE and ISO 26262, a solution will be developed to release a qualified product. This includes checking existing available approaches, such as those from RedHat.
Core Principles
- DRY (Don't Repeat Yourself): Centralize non-differentiating toolchain components so each project can focus on its domain-specific innovation
- Open Source by Default: Use open-source tools. Closed-source extensions may be integrated via well-defined plugin interfaces, but are never required
- Composable and Overlay Architecture: Projects can adopt the full toolchain or only the parts they need. Partial adoption is a first-class use case
The project will be hosted in one GitHub organization with multiple repositories. It will feature a modular architecture, ensuring that partial usage of the toolchain is possible. It will provide a central starting point for developers and support multiple languages, first including C++ and Rust.
Requirements will be defined through feature requests and issues, then reviewed with Eclipse SDV Working Group projects (e.g. presentation to the TAC).
Technical Details
The project is structured into four architectural layers, with AI integration running as cross-cuttingly across them.
Layer 1 - Build & Dependency Management:
Defines how the software is built and how dependencies are resolved. Built on Bazel as a starting point.
Layer 2 - Environment Management & Tool Provisioning:
Ensures all required tools and compilers are available in the correct version and configuration. Standardizes Environment Setup with tools like OCI-Container and other tools e.j. Nix, Moon/Proto (to be evaluated).
Layer 3 - Task Runner & Automation:
Provides a uniform command line interface for common workflows e.g. (build, test, lint, format, flash, run, package, simulate). Shields developers from underlying tool complexity. Aligns CI/CD pipelines, build agents, and remote execution with the same conventions used locally.
Layer 4 - Development Environment & Enablement:
Delivers a ready-to-use, pre-configured development environment with no manual setup.
Cross-cutting AI Integration:
Provides intelligent support across all layers: analyzes build/test/tooling outputs, suggests fixes and improvements, assists with configuration and workflow execution. Initial use case: automated dependency tree reasoning explaining why direct and transitive dependencies are included, useful for FOSS analysis.
Pros and Cons of the Proposed Solution
Pros:
- Eliminates redundant toolchain development across SDV projects, freeing resources for domain innovation
- The harmonized Bazel-based build system simplifies multi-project integration significantly
- Modular design allows partial adoption, no all-or-nothing migration required
- Qualification readiness (ASPICE, ISO 26262) reduces compliance effort per project
- Automated SBOM generation and FOSS/SCA scanning reduces security and license review overhead
Cons:
- Governance complexity: cross-project decisions require broader consensus, which may slow iteration
- Migration effort: existing projects face upfront investment to adapt to the unified toolchain
- Dependency risk: adopters become coupled to the project release cadence and maintenance health
Not known
The Eclipse Foundation provides the ideal environment to resolve current fragmentation within the SDV ecosystem, where projects independently develop individual toolchains. This centralized approach eliminates double work and reduces non-differentiating development efforts, allowing projects to focus on their domain specific content. By harmonizing the build system, the project simplifies the joint integration of multiple components into a unified project template. Hosting this project at the center of the community enables the resolution of existing pain points through direct feedback and ensures that open standards govern the integration process.
The project will focus on use and improve the existing toolchain of Eclipse S-CORE project, to determine how they can be adapted for broader ecosystem needs. A primary objective is to create a comprehensive toolchain landscape that identifies opportunities to reduce non-differentiating development efforts in individual Eclipse SDV projects. With two pilot projects Eclipse OpenSOVD and Eclipse Automotive API Framework we will introduce Bazel and Doc-as-Code in close collaboration with the Eclipse S-CORE project. An implementation for FOSS/SCA analysis and AI-assisted dependency reasoning is planned.
Future efforts will also focus on lowering the barrier of entry for developers, users, and adopters, ensuring they can become productive within the ecosystem immediately.
The project follows an evolutionary planning model; while a high-level roadmap exists, the concrete list of future tasks is intended to be flexible. This allows the project to adapt over time based on ongoing community discussions and emerging requirements defined through bodies like the Technical Advisory Committee (TAC).
-
Proposal and Provisioning (months 1–2)
-
Initial Contribution and MVP or called Release v0.1 (months 3–9)
-
Release 1.0 with basic features driven by the SDV Community and TAC ( month 9-18)
- Log in to post comments