Differences

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

--- en:safeav:softsys:lifecycleconfigmansupp [2026/06/17 14:15] – created karlisberkolds
+++ en:safeav:softsys:lifecycleconfigmansupp [2026/06/17 16:12] (current) – karlisberkolds
@@ Line 1: / Line 1: @@
 ====== Lifecycle, configuration management and supply chain ======
+====== Lifecycle models for autonomous software ======
+Software lifecycle models define how requirements, design, implementation, test, deployment and maintenance are organised. The waterfall model gives a simple sequential structure, but tends to discover integration defects late. Iterative and incremental models reduce this risk by delivering partial versions early. Agile methods improve feedback and adaptability, but must be constrained when safety evidence, traceability and certification are required. Spiral development emphasizes risk reduction and can be useful in large autonomy research programmes. DevOps integrates development, test, deployment and operational monitoring, which is important for connected autonomous systems that receive updates after release.
+Safety-critical autonomy cannot adopt any lifecycle model without modification. The book's central V-model remains the organising framework because it preserves traceability between specification and evidence. However, the V-model should not be interpreted as a one-pass waterfall. Modern projects often use incremental development inside V-model phases: prototypes and simulations mature requirements; software releases are integrated progressively; operational monitoring feeds back into hazard analysis and requirements refinement. The essential discipline is not the calendar shape of the process, but the preservation of bidirectional traceability and controlled baselines.
+<table Ref.Tab.3.3>
+<caption>Lifecycle models and their relevance for autonomous software</caption>
+^ Lifecycle model	  ^ Primary value  ^ 	Limitations for safety-critical autonomy     ^
+| Waterfall |	Clear sequence and documentation. |	Late feedback and poor adaptability. |
+| V-model |	Direct traceability between design levels and V&V evidence. |	Requires disciplined requirement and baseline control. |
+| Iterative/agile |	Early feedback and adaptation.	| Must be integrated with safety evidence and change impact analysis. |
+| Spiral |	Risk-driven exploration. |	Requires strong risk-management expertise. |
+| DevOps |	Automation, monitoring and continuous delivery. |	Needs controlled release gates, auditability and rollback for safety use. |
+</table>
+====== Configuration management and baseline control ======
+Configuration management is the discipline that keeps a software system stable while it evolves. It identifies configuration items, controls changes, records status and audits baselines. For an autonomous system, configuration items include source code, requirements, models, compiler versions, middleware configuration, calibration data, AI model weights, training datasets, test cases, container images, operating-system builds, safety manuals, SBOMs and deployed binaries. A release is safe only if its complete configuration can be reconstructed and related to the evidence used to approve it.
+The configuration-management cycle starts by identifying items and assigning unique versions. Change control then evaluates proposed modifications, including their impact on requirements, hazards, timing, security and certification evidence. Status accounting records which versions exist and where they are used. Configuration audits confirm that the tested and released product matches the approved baseline. Continuous review improves the process and reduces configuration drift.
+{{:en:safeav:softsys:chatgpt_image_jun_17_2026_03_03_57_pm.png?400|}}
+====== Software supply chain, maintainability and updates ======
+The software supply chain has become a major part of safety engineering. Modern products assemble operating systems, open-source components, vendor SDKs, protocol stacks, middleware, container bases, cryptographic libraries and cloud services. Open-source components provide transparency, reuse and innovation, but they also introduce obligations: vulnerability monitoring, licence compliance, long-term support, patch management and evidence that the component is appropriate for its safety role. A component may be technically reliable in an IT context but unsuitable for a safety-critical control path without additional containment and verification.
+Maintainability is a safety property over the product life. Autonomous systems often operate for years, while software dependencies and hardware platforms change much faster. A safe architecture needs separation between safety-critical and non-safety functions, explicit compatibility matrices, reproducible builds, update and rollback mechanisms, and a release process that prevents configuration drift. Over-the-air updates and software-defined features can reduce service cost and add capability, but they also transform validation into a continuing obligation after the first product release.
+====== Configuration-management activities and tools ======
+Configuration management is implemented through a set of recurring activities. Configuration identification defines what is controlled and how items are named. Configuration control defines how proposed changes are reviewed, approved, implemented and verified. Status accounting records the current and historical state of configuration items. Configuration audits confirm that documentation, software artefacts and released products match the approved baseline. Review and improvement ensure that the process remains effective as the system and organisation grow.
+Modern toolchains automate many of these activities. Version-control systems track source code, models and documents. Artefact repositories store binaries, containers and generated files. CI pipelines build, test and package software reproducibly. ALM tools link requirements to commits, reviews, tests and release records. Infrastructure-as-code tools capture deployment environments. Vulnerability scanners and SBOM tools support supply-chain governance. These tools are helpful only if they are integrated into the engineering workflow and treated as part of the evidence chain.
+Human factors remain a recurring risk. Teams under schedule pressure may bypass change control, modify configuration manually or treat documentation as separate from engineering. Automation should therefore reduce friction: pull requests should trigger traceability checks, builds should record tool versions automatically, test reports should be archived with the baseline, and release dashboards should show unresolved safety, security and configuration issues.
+<table Ref.Tab.4.4>
+<caption>Configuration and supply-chain challenges in autonomous software</caption>
+^ Challenge	  ^ Why it matters  ^ 	Engineering response  ^
+| Multiple variants |	Different sensors, ECUs, compute boards or mission packages may require different builds. |	Maintain a configuration matrix linking hardware, software, calibration and evidence. |
+| Continuous updates |	Fast releases can bypass traditional review and certification gates. |	Use release baselines, automated regression tests, staged rollout, monitoring and rollback. |
+| Dependency drift |	Untracked libraries, containers or cloud services can change behaviour. |	Use SBOMs, pinned dependencies, artefact repositories and vulnerability scanning. |
+| AI data versions |	A model cannot be reproduced without its data, training code and parameters. |	Apply MLOps versioning to datasets, labels, features, models and evaluation reports. |
+| Human process gaps |	Teams may treat CM as bureaucracy and bypass controls. |	Embed CM into pull requests, CI pipelines, code review and release automation. |
+</table>

en/safeav/softsys/lifecycleconfigmansupp.1781694910.txt.gz · Last modified: 2026/06/17 14:15 by karlisberkolds