This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revision | |||
en:safeav:as:vvintro [2025/06/27 13:58] – rahulrazdan | en:safeav:as:vvintro [2025/06/28 16:01] (current) – rahulrazdan | ||
---|---|---|---|
Line 4: | Line 4: | ||
<todo @rahulrazdan # | <todo @rahulrazdan # | ||
- | From a product development perspective, | + | As discussed in the governance module, whatever value products provide to their consumers is weighed against the potential harm caused by the product, and leads to the concept of legal product liability. |
{{: | {{: | ||
Line 24: | Line 25: | ||
In practice, each of these steps can have quite a bit of complexity and associated cost. Since the ODD can be a very wide state space, intelligently and efficiently generating the stimulus is critical. Typically, in the beginning, stimulus generation is done manually, but this quickly fails the efficiency test in terms of scaling. In virtual execution environments, | In practice, each of these steps can have quite a bit of complexity and associated cost. Since the ODD can be a very wide state space, intelligently and efficiently generating the stimulus is critical. Typically, in the beginning, stimulus generation is done manually, but this quickly fails the efficiency test in terms of scaling. In virtual execution environments, | ||
- | The execution stage can be done physically, but this process is expensive, slow, has limited controllability and observability, | ||
- | The observable results of the stimulus generation are captured to determine correctness. Correctness is typically defined by either a golden model or an anti-model. | ||
- | The MaVV consists of building a database of the various explorations of the ODD state space, and from that building an argument for completeness. The argument typically takes the nature of a probabilistic analysis. After the product is in the field, field returns are diagnosed, and one must always ask the question: Why did not my original process catch this issue? Once found, the test methodology is updated to prevent issues with fixes going forward. | ||
+ | {{: | ||
- | Ref: | + | The execution stage can be done physically |
- | - Razdan, R., (2019) “Unsettled Technology Areas in Autonomous Vehicle Test and Validation,” Jun. 12, 2019, EPR2019001. | + | The observable results of the stimulus generation are captured to determine correctness. Correctness is typically defined by either a golden model or an anti-model. |
- | - Razdan, R., (2019) “Unsettled Topics Concerning Automated Driving Systems | + | The MaVV consists of building a database of the various explorations of the ODD state space, and from that building an argument for completeness. The argument typically takes the nature of a probabilistic analysis. After the product is in the field, field returns are diagnosed, and one must always ask the question: Why did not my original process catch this issue? Once found, the test methodology is updated to prevent issues with fixes going forward. The V&V process is critical in building a product |
- | - Ross, K. Product Liability Law and its effect on product | + | |
+ | Finally, the product development process is typically focused on defining an ODD and validating against that situation. However, in modern times, an additional concern is that of adversarial attacks (cybersecurity). In this situation, an adversary wants to high jack the system for nefarious intent. In this situation, the product owner must not only validate against the ODD, but also detect when the system is operating outside the ODD. After detection, the best case scenario is to safely redirect the system to the ODD space. The risk associated with cybersecurity issues typically split at three levels for cyber-physical systems: | ||
+ | - OTA Security: | ||
+ | - Remote Control Security: | ||
+ | - Sensor Spoofing: | ||
+ | In terms of governance, some reasonable due-diligence is expected to be provided by the product developer in order to minimize these issues. The level of validation required is dynamic in nature and connected to the norm in the industry. | ||
- | 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. | ||
- | A. TRADITIONAL PHYSICS-BASED EXECUTION | ||
- | For MaVV, the critical factors are the efficiency of the MiVV “engine” and the argument for the completeness of the validation. Historically, | ||
- | 1) 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. | ||
- | 2) Monotonicity: | ||
- | Mechanically, | ||
- | 1) failure mechanisms are identified; | ||
- | 2) a test and safety argument is built to address the failure mechanism; | ||
- | 3) there is an active process by a regulator (or documentation for self-regulation) which evaluates these two, and acts as a judge to approve/ | ||
- | Traditionally, | ||
- | 1) 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). | ||
- | 2) Develop Functional Safety Concept: Translate safety goals into high-level safety requirements for the braking system. Ensure redundancy, diagnostics, | ||
- | 3) System Design and Technical Safety Concept: Break down functional safety requirements into technical requirements, | ||
- | 4) Hardware and Software Development: | ||
- | 5) 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), | ||
- | 6) 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. | ||
- | 7) Production, | ||
- | 8) 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). | ||
- | Historically, | ||
- | 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, | ||
- | In summary, the key underpinnings of the PBE paradigm from a V&V point of view are: | ||
- | 1) Constrained and well-behaved space for scenario test generation | ||
- | 2) Expensive physics based simulations | ||
- | 3) Regulations focused on mechanical failure | ||
- | 4) In safety situations, regulations focused on a process to demonstrate safety with a key idea of design assurance levels. | ||
- | B. TRADITIONAL DECISION-BASED EXECUTION | ||
- | As cyber-physical systems evolved, information technology (IT) rapidly transformed the world. Electronics design trends revolutionized industries, starting with centralized computing led by firms like IBM and DEC. These technologies enhanced productivity for global business operations, significantly impacting finance, HR, and administrative functions, eliminating the need for extensive paperwork. | ||
- | ---- | ||
- | {{: | ||
- | Fig. 3. Electronics Megatrends. | ||
- | |||
- | The next wave in economy shaping technologies consisted of edge computing devices (red in Figure 3) such as personal computers, cell phones, and tablets. With this capability, companies such as Apple, Amazon, Facebook, Google, and others could add enormous productivity to the advertising and distribution functions for global business. Suddenly, one could directly reach any customer anywhere in the world. This mega-trend has fundamentally disrupted markets such as education (online), retail (ecommerce), | ||
- | {{: | ||
- | Fig. 4. Progression of System Specification (HW, SW, AI). | + | |
- | + | ||
- | As shown in Figure 4, within electronics, | + | |
- | In their basic form, IT systems were not safety critical, and the similar levels of legal liability have not attached to IT products. However, the size and growth of IT is such that problems in large volume consumer products can have catastrophic economic consequences [10]. Thus, the V&V function was very important. | + | |
- | IT systems follow the same generic processes for V&V as outlined above, but with two significant differences around the execution paradigm and source of errors. First, unlike the PBE paradigm, the execution paradigm of IT follows a Decision Based Execution mode (DBE). That is, there are no natural constraints on the functional behavior of the underlying model, and no inherent properties of monotonicity. Thus, the whole massive ODD space must be explored which makes the job of generating tests and demonstrating coverage extremely difficult. | + | |
- | 1) Code Coverage: Here, the structural specification of the virtual model is used as a constraint to help drive the test generation process. This is done with software or hardware (RTL code). | + | |
- | 2) Structured Testing: A process of component, subsection, and integration testing has been developed to minimize propagation of errors. | + | |
- | 3) Design Reviews: Structured design reviews with specs and core are considered best practice. | + | |
- | + | ||
- | A good example of this process flow is the CMU Capability Maturity Model Integration (CMMI) [11] which defines a set of processes to deliver quality software. | + | |
- | Finally, testing in the DBE domain decomposes into the following philosophical categories: “Known knowns:” Bugs or issues that are identified and understood, “Known unknowns” Potential risks or issues that are anticipated but whose exact nature or cause is unclear, and “Unknown unknowns” Completely unanticipated issues that emerge without warning, often highlighting gaps in design, understanding, | + | |
- | In summary, the key underpinnings of the DBE paradigm from a V&V point of view are: | + | |
- | 1) Unconstrained and not well-behaved execution space for scenario test generation, | + | |
- | 2) Generally, | + | |
- | 3) V&V focused on logical errors not mechanical failure | + | |
- | 4) Generally, | + | |
- | 5) “Unknown-unknowns” a key focus of validation. | + | |
- | + | ||
- | A key implication of the DBE space is that the idea from the PBE world of building a list of faults and building a safety argument for them is antithetical to the focus of DBE validation. | + |