Differences

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

--- en:safeav:as:vreq [2026/05/18 15:03] – pczekalski
+++ en:safeav:as:vreq [2026/06/02 15:50] (current) – raivo.sell
@@ Line 28: / Line 28: @@
 Emerging efforts like the SAE G-34/SC-21 standard for AI in aviation, NASA's exploration of adaptive autonomy, and ISO’s work on AI functional safety indicate a trend toward domain-agnostic principles for validating intelligent behavior. There is growing recognition that autonomous systems, regardless of environment, need rigorous testing of edge cases, clarity of system intent, and real-time assurance mechanisms.
+===== Autonomy Validation Tools =====
+<note>From ch. 8.0</note>
+Validation and verification (V&V) are critical processes in systems engineering and software development that ensure a system meets its intended purpose and functions reliably. **Verification** is the process of evaluating whether a product, service, or system complies with its specified requirements—essentially asking, "Did we build the system right?" It involves activities such as inspections, simulations, tests, and reviews throughout the development lifecycle. **Validation**, on the other hand, ensures that the final system fulfills its intended use in the real-world environment—answering the question, "Did we build the right system?" This typically includes user acceptance testing, field trials, and performance assessments under operational conditions. Together, V&V help reduce risks, improve safety and quality, and increase confidence that a system will operate effectively and as expected.  In the context of autonomous systems, V&V combines two historical trends.  The first from the mechanical systems and the second more recent one from classical digital decision systems.  Finally, AI adds further complexity to the testing of the digital decision systems.
+For traditional safety-critical systems in automotive, 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.
+  - Formalization: The formal definition of system operating conditions, functionalities, expected behaviors, risks, and hazards that must be mitigated.
+  - Lifecycle Management: The management of components, systems, and development processes throughout their lifecycle.
+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.
+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.
+{{:en:safeav:as:table1.png?400|}}
+Table one above shows the difference between ISO 26262 and SOTIF. In general, the fundamental characteristics of digital software systems are problematic in safety critical systems. However, the IT sector has been a key megatrend which has transformed the world over the last 50 years. In the process, it has developed large ecosystems around semiconductors, operating systems, communications, and application software. At this point, using these ecosystems is critical to nearly every product’s success, so mixed-domain safety critical products are now a reality. Mixed Domain structures can be classified in three broad paradigms each of which have very different V&V requirements: Mechanical Replacement (Big Physical, small Digital), Electronic Adjacent (separate Physical and Digital), autonomy (Big Digital, small Physical).
+Drive-by-Wire functionality is an example of the mechanical replacement paradigm where the implementation of the original mechanical functionality is done by electronic components (HW/SW). In their initial configurations, these mixed electronic/mechanical systems were physically separated as independent subsystems. In this configuration, the V&V process looked very similar to the traditional mechanical verification process.
+The paradigm of separate physical subsystems has the advantage of V&V simplification and safety, but the large disadvantage of component skew and material cost. Thus, an emerging trend has been to build underlying computational fabrics with networking and virtually (through software) separate functionality.  From a V&V perspective, this means that the virtual backbone which maintains this separation (ex: RTOS) must be verified to a very high standard. Infotainment systems are an example of Electronics Adjacent integration. Generally, there is an independent IT infrastructure working with the safety critical infrastructure, and from a V&V perspective, they can be validated separately.   However, the presence of infotainment systems enables very powerful communication technologies (5G, Bluetooth, etc.) where the cyber-physical system can be impacted by external third parties.  From a safety perspective, the simplest method for maintaining safety would be to physically separate these systems. However, this is not typically done because a connection is required to provide “over-the-air” updates to the device.   Thus, the V&V capability must again verify the virtual safeguards against malicious intent are robust.
+Finally, the last level of integration is in the context of autonomy.  In autonomy, the processes of sensing, perception, location services, path planning envelope the traditional mechanical functionality.
+{{:en:safeav:avt:ai_sw_dev.jpg?600|}}
+Moving beyond software, AI has built a “learning” paradigm. In this paradigm, there is a period of training where the AI machine “learns” from data to build its own rules, and in this case, learning is defined on top of traditional optimization algorithms which try to minimize some notion of error. This effectively is data driven software development as shown in figure below.
+However,there are profound differences between AI software and conventional software.  The introduction of AI generated software introduces significant issues to the V&V task as shown in table 2 below.
+{{:en:safeav:avt:table2.png?600|}}

en/safeav/as/vreq.1779105803.txt.gz · Last modified: 2026/05/18 15:03 by pczekalski