Configuration Management#

Concept#

Configuration Management Concept
status: valid
status: valid

In this section a concept for the configuration management will be discussed. Inputs for this concepts are mainly the requirements of ISO26262 “Part 8: Supporting Processes” and ASPICE Requirements from PAM4.0, SUP.8

Inputs#

  1. Stakeholders for the configuration process work products?

  2. Who needs which information?

  3. Which work products do we have?

  4. What tooling do we need?

Stakeholders#

  1. Technical Lead (rl__technical_lead)

    • for creating a module or a platform release a baseline of all configuration items is needed

  2. Contributor (rl__contributor) and Committer (rl__committer)

    • wants know which configuration items version has to be used as input for his work

    • wants to share their created work product with others for example to get those reviewed

    • wants to integrate share their created work product with other work products

note: configuration items are all defined S-CORE work products plus additional arefacts not produced by S-CORE needed for the building of the documentation and verification reports (e.g. tools, external SW libraries)

Work Products#

Configuration Management Plan (doc__config_mgt_plan) is a document and part of the work product Platform Management Plan (wp__platform_mgmt).

Configuration Management Tooling#

Almost all requirements of the standards towards configuration management can be covered by standard tooling of the Eclipse Foundation (github for versioning) and of the S-CORE project (sphinx-needs for text based identification of work products).

For the automated storage additional tooling is created (see Configuration Management Process Requirements)

Getting started#

Configuration Management Get Started
status: valid
status: valid

In case you are appointed as a Technical Lead (rl__technical_lead) by the Project Lead (rl__project_lead) in the S-CORE project:

  • On platform level, process community already provided a draft configuration management plan, see Configuration Management Plan (doc__config_mgt_plan), just set it to “valid”

  • On module level, create a configuration management plan using the platform one as a template. If no configuration management plan on module level is created, the platform one is adopted.

As a normal contributor or committer consult the Configuration Management Plan (doc__config_mgt_plan), but this should not differ from normal usage of github as a configuration management tool.

Workflows#

The main work product is the configuration management plan, which is a part of the platform management plan. Thus the work flow Create/Maintain Platform Ma... (wf__platform__cr_mt_platform_mgmt_plan) applies.

Baselines (sets of workproducts and their versions) defining a SW Release on platform or module level are created as part of this process but are documented in the respective release notes.

Guidance#

The configuration management guideline is contained within the configuration management plan, to have all relevant information in one space, see Configuration (gd_guidl__configuration)

Some process requirements to be automated are available: