Frequently Asked Questions

Eclipse S-CORE develops a shared, open-source software platform for onboard automotive ECUs. The platform is maintained across multiple repositories; the separate Reference Integration brings modules together and verifies them as a baseline.

Communities handle cross-cutting topics such as architecture, process, infrastructure, testing, and integration. Feature Teams own specific functionality end to end, from architecture through integration testing. See the Project Management Plan.

The Project Lead Circle and Technical Lead Circle coordinate strategic and technical steering. Communities and Feature Teams organize work in their respective areas; their membership and responsibilities vary. See the Project Management Plan.

Project and technical steering are coordinated through the Project Lead Circle and Technical Lead Circle. Communities and Feature Teams plan and carry out work, with public meetings and notes documented through project channels. The Project Management Plan describes the current organization.

S-CORE follows Eclipse Foundation project governance. Current responsibilities and organization are described in the Project Management Plan; committer and project-lead elections follow the applicable Eclipse Project Handbook.

Releases baseline development activities; milestones mark scheduled project outcomes. Overall planning is coordinated by the Project and Technical Lead Circle, while teams plan their work in their project boards. See the Project Management Plan and current Reference Integration releases.

GitHub is used for source code, issues, and pull requests; Bazel is used for builds; and project documentation is generated with Sphinx-based tooling. The exact setup is documented in the infrastructure and tooling docs.

The score platform repository contains platform-level features, requirements, and architecture. Each module repository owns its module requirements, architecture, implementation, and tests. The separate Reference Integration publishes consolidated integration documentation and verification information.

Technical steering is coordinated by the Technical Lead Circle together with the Project Lead Circle. Technical and project responsibilities are described in the Project Management Plan.

Teams plan and track their own work in GitHub Projects. The Project and Technical Lead Circle coordinate the overall top-down plan, milestones, and releases. See Planning and Tracking in the Project Management Plan.

S-CORE targets high-performance automotive ECUs; do not assume a 32-bit microcontroller is supported. Suitability depends on the hardware, operating system, and selected modules. Check the current platform assumptions and the Reference Integration for supported configurations.

S-CORE includes C++ and Rust modules. Required language standards and supported subsets can vary by module and toolchain; check the relevant module documentation and the C++ and Rust toolchain repositories for current details.

Feature Requests propose a new feature or a major feature change and follow the Feature Enhancement Proposal process. Component Requests cover changes within an existing feature and are handled with the responsible team. See the contribution request guide.

Use the current GitHub issue template for the request type; it defines the required information. The Project Management Plan describes common tracking fields and issue categories.

S-CORE publishes platform safety documentation and assumptions of use, but this does not certify a vehicle program’s final system. Integrators must assess their selected hardware, operating system, modules, and safety goals, and provide any additional verification needed. Start with the Safety documentation and platform assumptions.

Platform changes are tracked through GitHub issues and pull requests. The Reference Integration combines selected modules and verifies them together; system integrators still need to validate their own target configuration.

Report bugs and propose improvements through GitHub Issues. Use the issue template that best matches the problem or request; the contributor guide explains the project workflow.

Start with a Feature Request that describes the motivation, intended functionality, and requirements. New or major feature changes follow the Feature Enhancement Proposal process; the current requests are tracked on the Feature Request Board.

The Architecture Community reviews Feature Enhancement Proposals through a shepherd and Final Comment Period. The Project and Technical Lead Circle triage incoming requests for project planning; Component Requests are discussed with the responsible team. See the contribution request guide.

Contributors need an Eclipse Foundation account. For contributions to be attributed to an organization, use the corporate email associated with that account for Git commits and link the account to the employer. Follow the current contribution attribution guidance.

This allows eligible contributions to be attributed to the organization in project contribution reporting. The attribution guide explains the account, employer, and commit-email requirements.

The contribution request guide covers Feature Requests, Component Requests, and the pull request workflow.

Pull requests are reviewed by automatically assigned reviewers based on repository CODEOWNERS, and must pass the applicable checks before merge. See the pull request guidance.