Change: Configuration Guideline for Module Configuration

[AThums]

Change Request Type

Feature Request

Description of the Change Request

Goal:
Improve User Experience through a unified and consistent static module configuration in S-CORE.

Problem Statement
Currently, modules are created by different contributors, each following their own experience and style. This leads to inconsistencies in static configuration, such as:

Different constructs for unique identifiers: Identifier, Specifier, AppName
Inconsistent naming of configuration variables
Different storage locations for configuration files
This diversity makes understanding, maintenance, and integration of modules more difficult.

Target Picture
A Configuration Guideline that defines binding rules and best practices for all static configurations to:

Ensure consistent naming conventions for configuration variables
Define and use unique identifiers consistently
Specify the storage location and format of configuration files
Provide a clear structure for configuration parameters (e.g., mandatory fields, optional fields, default values)
Scope

Applies to static configurations within S-CORE
Considers future extensions (e.g., JSON support, FlatBuffers)
Acceptance Criteria

Documented guideline is available and accessible to all contributors
Examples of correct application of the guideline are included
(optional) Automated checks for compliance with the guideline are provided
All new modules must comply with the guideline
Business Value

Consistency: Unified configuration improves understanding and reduces errors
Efficiency: Faster integration of new modules
Maintainability: Easier maintenance and extension of the system
User Experience: Clear and predictable configuration for users

Estimates for realization

Part A — Create, align, and document the configuration model & guideline

Output: A versioned Configuration Guideline, a reference model, example configurations, and (optional) automated checks.
Approach: Iterative, step-by-step, focusing only on current S‑CORE features.

Part B — Adapt existing module configurations to the model & guideline

Output: Updated configuration files across modules, minimal changes (primarily naming), plus changelog and migration notes.
Constraint: “Common model should reflect available configurations”; expectation is minimal adaptations.

Affects work products

• Requirements
• Architecture
• Safety/Security Analysis
• Detailed Design

Impact analysis

• Architecture: common configuration model is part of the architecture
• process: configuration guideline will be part of the process description
• detailed design: feature configuration models must adhere to the defined model --> smaller adaptions could be possible

Safety or Security relevance

• none
• Safety relevant
• Security relevant

ASIL classification

QM

Expected Implementation Version

1.0

[AThums]

Replaces issue #2217 , as it did not follow the prescribed template