Software Architecture Overview#

The following picture shows the high-level architecture of the Eclipse S-CORE platform. It is the same picture as on the Platform Architecture page, which is the single source of truth. The architecture is continuously refined and will evolve in future releases.

Eclipse S-CORE platform architecture overview

Reading the picture#

The platform is organized in layers. From top to bottom:

  • Frameworks — domain-specific frameworks on which applications are built, e.g. for ADAS the Fixed Execution Order (FEO) framework and the Deterministic App Abstraction Layer (DAAL), or the AI Platform. Applications and domain frameworks for other domains (e.g. telematics) are shown for context only.

  • Platform API — the native C++ and Rust APIs that applications use, e.g. for logging, persistency, time, lifecycle, communication, diagnostics and crypto.

  • Platform services — the implementations behind these APIs, grouped into Base Services (logging, tracing, persistency, time, software update), Application Management (lifecycle, health management), Communication (zero-copy IPC, SOME/IP and DDS gateways), Diagnosis and Security.

  • Common — functionality shared by all other parts, such as the base libraries (baselibs) and configuration management.

  • Operating System and Hypervisor / Hardware — S-CORE builds on existing POSIX-compliant operating systems (e.g. QNX, Linux) instead of developing its own. The expectations towards the operating system are described in the OS module and as assumptions of use in the platform assumptions.

The colors indicate the status of each building block: in development, for future, not part of development, out of scope, or part of the operating system / hardware specific implementation. The box on the right side shows that S-CORE can run next to a non-converged system, e.g. an IVI system with Android.

From features to modules#

The architecture is described on two levels, which you will find again in all S-CORE repositories:

  • A Feature is a logical entity of the platform (e.g. Persistency or Communication). Feature requirements and the feature architecture are maintained in this repository, see Platform Features.

  • A Module is the physically built and released unit that implements one or more features. Each module lives in its own repository and contains the component requirements, component architecture, detailed design, implementation and tests, see Modules and the module structure overview.

The relation between both levels is explained in the building blocks concept of the process description.

Evolving the architecture#

Eclipse S-CORE has a software architecture community responsible for maintaining and evolving the architecture.

Structural changes and new functionality are proposed through a Feature & Enhancement Proposal (FEP). All past feature requests are documented in the corresponding Feature Requests / Modification GitHub project.

Submitting a FEP is described in the Feature & Enhancement Proposal (FEP) guideline. Larger architectural decisions are documented as decision records in the design decisions section. Participation in the architecture process is encouraged.

The software architecture community regularly organizes workshops where contributors can:

  • present new ideas

  • discuss approved new feature requests, and

  • evaluate whether existing solutions from other projects can be adopted.

These workshops are open for participation both online and onsite.