Differences

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

--- en:safeav:as:vvintro [2025/06/16 01:42] – ToDo checked: rahulrazdan
+++ en:safeav:as:vvintro [2025/06/28 16:01] (current) – rahulrazdan
@@ Line 3: / Line 3: @@
 <todo @rahulrazdan #rahulrazdan:2025-06-16></todo>
+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. From a product development perspective, the combination of laws, regulations, legal precedence form the overriding governance framework around which the system specification must be constructed [3].   The process of validation ensures that a product design meets the user's needs and requirements, and verification ensures that the product is built correctly according to design specifications.
+{{:en:safeav:as:picture1.png?400|}}
+Fig. 1. V&V and Governance Framework.
+The Master V&V(MaVV) process needs to demonstrate that the product has been reasonably tested given the reasonable expectation of causing harm. It does so using three important concepts [4]:
+  - Operational Design Domain (ODD): This defines the environmental conditions and operational model under which the product is designed to work.
+  - Coverage: This defines the completeness over the ODD to which the product has been validated.
+  - Field Response: When failures do occur, the procedures used to correct product design shortcomings to prevent future harm.
+As figure 1 shows, the Verification & Validation (V&V) process is the key input into the governance structure which attaches liability, and per the governance structure, each of the elements must show “reasonable due diligence.”  An example of unreasonable ODD would be for an autonomous vehicle to give up control a millisecond before an accident.
+{{:en:safeav:as:picture2.png?400|}}
+Fig. 2. Execution is space.
+Mechanically, MaVV is implemented with a Minor V&V (MiVV) process consisting of:
+  - Test Generation: From the allowed ODD, test scenarios are generated.
+  - Execution:  This test is “executed” on the product under development. Mathematically, a functional transformation which produces results.
+  - Criteria for Correctness: The results of the execution are evaluated for success or failure with a crisp criteria-for-correctness.
+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, pseudo-random directed methods are used to accelerate this process. In limited situations, symbolic or formal methods can be used to mathematically carry large state spaces through the whole design execution phase. Symbolic methods have the advantage of completeness but face algorithmic computational explosion issues as many of the operations are NP-Complete algorithms.
+{{:en:safeav:as:zalazone_drone_0.jpg?400|}}
+The execution stage can be done physically (such as test track above), but this process is expensive, slow, has limited controllability and observability, and in safety critical situations, potentially dangerous. In contrast, virtual methods have the advantage of cost, speed, ultimate controllability and observability, and no safety issues. The virtual methods also have the great advantage of performing the V&V task well before the physical product is constructed. This leads to the classic V chart shown in figure 1. However, since virtual methods are a model of reality, they introduce inaccuracy into the testing domain while physical methods are accurate by definition. Finally, one can intermix virtual and physical methods with concepts such as Software-in-loop or Hardware-in-loop.
+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 golden model, typically virtual, offers an independently verified model whose results can be compared to the product under test.  Even in this situation, there is typically a divergence between the abstraction level of the golden model and the product which must be managed. Golden model methods are often used in computer architectures (ex ARM, RISCV). The anti-model situation consists of error states which the product cannot enter, and thus the correct behavior is the state space outside of the error states. An example might be in the autonomous vehicle space where an error state might be an accident or violation of any number of other constraints.
+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 which meets customer expectations and documents the need for "reasonable" due diligence for the purposes of product liability in the governance framework.
+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:  If an adversary can take manipulate the Over the Air (OTA) software updates, they can take over mass number of devices quickly.  An example worst case situation would be a Tesla OTA which turns Tesla's into collision engines.
+  - Remote Control Security:  If the adversary can take over a car remotely, they can cause harm to the occupants as well as third-parties.
+  - Sensor Spoofing:  In this situation, the adversary uses local physical assets to fool the sensors of the target. GPS jamming or spoofing are active examples.
+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.

en/safeav/as/vvintro.1750038121.txt.gz · Last modified: 2025/06/16 01:42 by rahulrazdan