Differences

This shows you the differences between two versions of the page.

--- en:safeav:softsys:configuration [2025/10/17 12:33] – created agrisnik
+++ en:safeav:softsys:configuration [2025/10/17 12:44] (current) – agrisnik
@@ Line 15: / Line 15: @@
   * **Maintain compliance** – in safety-critical domains (automotive, aerospace), regulatory standards require version control and change tracking.
   * **Support automation** – CI/CD pipelines rely on version-controlled repositories and configuration metadata.
+<figure The Role of Configuration Management  >
+{{ :en:safeav:as:as:rtu_ch4_figure6.png?400| The Role of Configuration Management }}
+<caption>The Role of Configuration Management (Adapted from ((Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner’s Approach (9th ed.). McGraw-Hill)) ((IEEE. (2012). ISO/IEC/IEEE 828: Configuration Management in Systems and Software Engineering. IEEE Standards Association.))) </caption>
+</figure>
+===== Key Concepts in Configuration Management =====
+To understand CM, several foundational terms must be defined.
+**Configuration Item (CI)**
+A Configuration Item is any component of the system that is subject to configuration control. Examples include:
+  * Source code files
+  * Build scripts and binaries
+  * Databases and configuration files
+  * Test scripts and reports
+  * Documentation and requirement specifications
+  * Firmware or deployed container images
+Each CI is uniquely identified, versioned, and tracked over time ((Sommerville, I. (2016). Software Engineering (10th ed.). Pearson)).
+**Baseline**
+A baseline is a formally approved version of one or more configuration items that serves as a reference point. Once established, any changes to the baseline must follow a defined change control process.
+Types of baselines:
+  * Functional baseline – system requirements approved for development.
+  * Allocated baseline – subsystem design completed and approved.
+  * Product baseline – tested and released version ready for delivery.
+Baselines create stability checkpoints in the lifecycle ((Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner’s Approach (9th ed.). McGraw-Hill.)).
+**Version Control**
+Version control systems (VCS), such as Git, Mercurial, or Subversion, track and manage modifications to source code and other files. They enable:
+  * Team collaboration.
+  * Historical traceability.
+  * Branching and merging for feature development.
+Version control forms the technical backbone of configuration management.
+**Change Management**
+Change management defines how modifications are proposed, evaluated, approved, and implemented. Typical steps:
+  * **Request** – a developer or stakeholder submits a change request (CR).
+  * **Impact analysis** – assess implications on cost, schedule, and performance.
+  * **Approval** – change control board (CCB) reviews and authorises.
+  * **Implementation and verification** – perform and test the change.
+  * **Documentation and closure** – record and archive results.
+This structured approach ensures accountability and quality control ((IEEE. (2012). ISO/IEC/IEEE 828: Configuration Management in Systems and Software Engineering. IEEE Standards Association)).
+**Configuration Audit**
+A configuration audit verifies that the configuration items and documentation:
+  * Match the approved baseline.
+  * Have passed required verification steps.
+  * Are properly labelled and traceable.
+Two common types:
+  * Functional Configuration Audit (FCA): Confirms functional requirements are met.
+  * Physical Configuration Audit (PCA): Confirms physical configuration matches documentation.
+Audits maintain integrity and compliance, especially in defence and aerospace projects ((NASA. (2021). Configuration Management Procedural Requirements (NPR 7120.5E). National Aeronautics and Space Administration)).
+===== Challenges in Configuration Management =====
+Even though CM brings structure and order, it faces numerous practical challenges, particularly in distributed and complex systems.
+**Complexity and Scale**
+Modern systems can contain millions of lines of code, hundreds of dependencies, and multiple configurations for different platforms. Managing all these variations manually is infeasible. Example:
+An autonomous vehicle might include distinct configurations for:
+  * Development simulations
+  * Real-time embedded control
+  * Cloud analytics backend
+Solution: Automated configuration management with metadata-driven tools (e.g., Ansible, Puppet, Kubernetes Helm).
+**Multiple Development Streams**
+In large projects, teams work on multiple branches or versions simultaneously (e.g., development, testing, release).
+This increases the risk of:
+  * Code divergence and merge conflicts.
+  * Dependency mismatches.
+  * Integration bottlenecks.
+Solution:
+  * Enforce branching strategies (GitFlow, trunk-based development).
+  * Integrate CI/CD pipelines for automated testing and builds.
+**Hardware–Software Interdependencies**
+In embedded or cyber-physical systems, configurations depend on hardware variants (processors, sensors, memory). Maintaining alignment between software builds and hardware specifications is difficult. Mitigation:
+  * Maintain configuration matrices mapping software versions to hardware variants.
+  * Employ digital twins for verification ((Wang, L., Xu, X., & Nee, A. Y. C. (2022). Digital twin-enabled integration in manufacturing. CIRP Annals, 71(1), 105–128.)).
+**Frequent Updates and Continuous Delivery**
+In the DevOps era, software may be updated multiple times per day across thousands of devices. Each update must maintain consistency and rollback capability.
+Challenge:
+  * Balancing speed (Agile/DevOps) with control (safety and certification).
+Solution:
+  * Versioned deployment pipelines.
+  * Canary releases and A/B testing.
+  * Immutable infrastructure (containers and images stored as CIs).
+**Data and Configuration Drift**
+Configuration drift occurs when the system’s actual state deviates from its documented configuration — common in dynamic, cloud-based systems.
+Causes:
+  * Manual changes bypassing automation.
+  * Untracked dependencies.
+  * Environment-specific overrides.
+Prevention:
+  * Use Infrastructure as Code (IaC) for full traceability.
+  * Periodic configuration audits and compliance scanning (e.g., Chef InSpec, AWS Config).
+**Regulatory and Compliance Demands**
+In domains like aerospace, medical, and automotive, configuration management is a compliance requirement under standards such as  ISO/IEC/IEEE 12207, ISO 26262 or IEC 61508
+Challenge:
+  * Maintaining traceability between requirements, code, and tests through continuous change cycles.
+Solution:
+  * Use integrated Application Lifecycle Management (ALM) platforms (e.g., IBM DOORS, Siemens Polarion) that link requirements, commits, and test cases.
+**Human and Organisational Factors**
+The most difficult aspect of CM is often cultural, not technical. Teams may resist documentation or formal change control due to perceived bureaucracy. As a result:
+  * Changes occur without review.
+  * Records become incomplete.
+  * Knowledge is lost during turnover.
+Solution:
+  * Establish clear CM policies and training.
+  * Promote configuration discipline as a core part of engineering culture.
+  * Integrate CM practices seamlessly into daily workflows (e.g., automated pull requests and code reviews).

en/safeav/softsys/configuration.1760704435.txt.gz · Last modified: 2025/10/17 12:33 by agrisnik