Differences

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

Link to this comparison view

--- en:safeav:as:automanual [2025/06/30 02:35] – rahulrazdan
+++ en:safeav:as:automanual [2025/07/02 12:56] (current) – pczekalski
@@ Line 1: / Line 1: @@
 ====== Intersection of Autonomy with Governance ======
-{{:en:iot-open:czapka_m.png?50| Masters (2nd level) classification icon }}
+{{:en:iot-open:czapka_b.png?50| Bachelors (1st level) classification icon }}
 <todo @rahulrazdan #rahulrazdan:2025-06-16></todo>
-For safety-critical systems, the evolution of V&V has been closely linked to regulatory standards frameworks such as ISO 26262. Key elements of this framework include:
-)	System Design Process: A structured development assurance approach for complex systems, incorporating safety certification within the integrated development process.
+In most cases, the generic V&V process must grapple with massive ODD spaces, limited execution capacity, and high cost of evaluation. Further, all of this must be done in a timely manner to make the product available to the marketplace.  Traditionally, the V&V regimes have been bifurcated into two broad categories: Physics-Based and Decision-Based. We will discuss the key characteristics of each now.
-)	Formalization: The formal definition of system operating conditions, functionalities, expected behaviors, risks, and hazards that must be mitigated.
+	A. TRADITIONAL PHYSICS-BASED EXECUTION
-)	Lifecycle Management: The management of components, systems, and development processes throughout their lifecycle.
+For MaVV, the critical factors are the efficiency of the MiVV “engine” and the argument for the completeness of the validation. Historically, mechanical/non-digital products (such as cars or airplanes) required sophisticated V&V.  These systems were examples of a broader class of products which had a Physics-Based Execution (PBE) paradigm.  In this paradigm, the underlying model execution (including real life) has the characteristics of continuity and monotonicity because the model operates in the world of physics. This key insight has enormous implications for V&V because it greatly constrains the potential state-space to be explored. Examples of this reduction of state-space include:
-The primary objective was to meticulously and formally define the system design, anticipate expected behaviors and potential issues, and comprehend the impact over the product's lifespan.
+)	Scenario Generation: One need only worry about the state space constrained by the laws of physics. Thus, objects which defy gravity cannot exist. Every actor is explicitly constrained by the laws of physics.
-With the advent of conventional software paradigms, safety-critical V&V adapted by preserving the original system design approach while integrating software as system components. These software components maintained the same overall structure of fault analysis, lifecycle management, and hazard analysis within system design. However, certain aspects required extension. For instance, in the airborne domain, standard DO-178C, which addresses "Software Considerations in Airborne Systems and Equipment Certification," updated the concept of hazard from physical failure mechanisms to functional defects, acknowledging that software does not degrade due to physical processes. Also revised were lifecycle management concepts, reflecting traditional software development practices. Design Assurance Levels (DALs) were incorporated, allowing the integration of software components into system design, functional allocation, performance specification, and the V&V process, akin to SOTIF in the automotive industry.
+)	Monotonicity: In many interesting dimensions, there are strong properties of monotonicity.  As an example, if one is considering stopping distance for braking, there is a critical speed above which there will be an accident. Critically, all the speed bins below this critical speed are safe and do not have to be explored.
+Mechanically, in traditional PBE fields, the philosophy of safety regulation (ISO 26262 [5], AS9100 [6], etc.) builds the safety framework as a process, where
+)	failure mechanisms are identified;
+)	a test and safety argument is built to address the failure mechanism;
+)	there is an active process by a regulator (or documentation for self-regulation) which evaluates these two, and acts as a judge to approve/decline.
+Traditionally, faults considered were primarily mechanical failure. As an example, the flow for validating the braking system in an automobile through ISO 26262 would have the following steps:
+)	Define Safety Goals and Requirements (Concept Phase): Hazard Analysis and Risk Assessment (HARA): Identify potential hazards related to the braking system (e.g., failure to stop the vehicle, uncommanded braking). Assess risk levels using parameters like severity, exposure, and controllability. Define Automotive Safety Integrity Levels (ASIL) for each hazard (ranging from ASIL A to ASIL D, where D is the most stringent). Define safety goals to mitigate hazards (e.g., ensure sufficient braking under all conditions).
+)	Develop Functional Safety Concept: Translate safety goals into high-level safety requirements for the braking system. Ensure redundancy, diagnostics, and fail-safe mechanisms are incorporated (e.g., dual-circuit braking or electronic monitoring).
+)	System Design and Technical Safety Concept: Break down functional safety requirements into technical requirements, design the braking system with safety mechanisms like (Hardware {e.g., sensors, actuators. Software (e.g., anti-lock braking algorithms). Implement failure detection and mitigation strategies (e.g., failover to mechanical braking if electronic control fails).
+)	Hardware and Software Development: Hardware Safety Analysis (HSA): Validate that components meet safety standards (e.g., reliable braking sensors). Software Development and Validation: Use ISO 26262-compliant processes for coding, verification, and validation. Test braking algorithms under various conditions.
+)	Integration and Testing: Perform verification of individual components and subsystems to ensure they meet technical safety requirements. Conduct integration testing of the complete braking system, focusing on: Functional tests (e.g., stopping distance), Safety tests (e.g., behavior under fault conditions), and Stress and environmental tests (e.g., heat, vibration).
+)	Validation (Vehicle Level): Validate the braking system against safety goals defined in the concept phase. Perform real-world driving scenarios, edge cases, and fault injection tests to confirm safe operation. Verify compliance with ASIL-specific requirements.
+)	Production, Operation, and Maintenance: Ensure production aligns with validated designs, implement operational safety measures (e.g., periodic diagnostics, maintenance), monitor and address safety issues during the product's lifecycle (e.g., software updates).
+)	Confirmation and Audit: Use independent confirmation measures (e.g., safety audits, assessment reviews) to ensure the braking system complies with ISO 26262.
+Finally, the regulations have a strong idea of safety levels with Automotive Safety Integrity Levels (ASIL).  Airborne systems follow a similar trajectory (pun intended) with the concept of Design Assurance Levels (DALs). A key part of the V&V task is to meet the standards required at each ASIL level.
+Historically, a sophisticated set of V&V techniques has been developed to verify traditional automotive systems.  These techniques included well-structured physical tests, often validated by regulators, or sanctioned independent companies (ex TUV-Sud [7]).
+Over the years, the use of virtual physics-based models has increased to model design tasks such as body design [8] or tire performance [9].  The general structure of these models is to build a simulation which is predictive of the underlying physics to enable broader ODD exploration. This creates a very important characterization, model generation, predictive execution, and correction flow.  Finally, because the execution is highly constrained by physics, virtual simulators can have limited performance and often require extensive hardware support for simulation acceleration.
+In summary, the key underpinnings of the PBE paradigm from a V&V point of view are:
+)	Constrained and well-behaved space for scenario test generation
+)	Expensive physics based simulations
+)	Regulations focused on mechanical failure
+)	In safety situations, regulations focused on a process to demonstrate safety with a key idea of design assurance levels

en/safeav/as/automanual.1751250943.txt.gz · Last modified: 2025/06/30 02:35 by rahulrazdan