Differences

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

--- en:safeav:softsys:summary [2026/04/08 10:32] – airi
+++ en:safeav:softsys:summary [2026/04/24 09:58] (current) – raivo.sell
@@ Line 1: / Line 1: @@
 ====== Summary ======
-This chapter has provided an overviews of autonomous systems (ground, airborne, marine, space), the initial framing of expectation functions for autonomy, the governance structures into which autonomy must operate, an overview of the validation and verification mechanisms used to support these governance structures, and finally an overview of autonomy in each of the physical domains.
+This chapter traces the evolution of software from programmable hardware foundations to a dominant force in modern computing systems. Early advances in hardware programmability—through configuration, programmable logic (e.g., FPGAs), and stored-program processors—enabled a separation between physical implementation and functional behavior. The introduction of stable computer architectures (notably IBM System/360) and operating systems created enduring abstractions that allowed software portability, scalability, and rapid innovation. Over time, networking and open-source ecosystems further accelerated the growth of information technology, establishing software as the central driver of capability across computing platforms.
-In the subsequent chapters, we will delve deeper into these topics with a framing informed by autonomy abstractions as shown in the figure below.  At the “bottom” of these abstractions are the physical objects such as the mechanical devices and the associated electronics hardware.  Layered above the electronics hardware layer are various software layers which start with middleware/infrastructure, algorithmic layers, and finally the connection to humans.
+As software methods entered cyber-physical systems (CPS)—including ground, airborne, marine, and space domains—they followed a distinct trajectory shaped by real-time constraints, safety requirements, and physical interaction. Initially introduced to enhance control and diagnostics, software evolved into the core coordinating layer for sensing, decision-making, and actuation, enabling autonomy. This transition was supported by the emergence of real-time operating systems (RTOSes), middleware, and layered software architectures that ensured deterministic behavior and modularity. Across all domains, systems evolved from isolated, hardware-centric designs to distributed, software-intensive platforms, with increasing reliance on standardized frameworks and communication protocols.
-{{:en:safeav:softsys:figure2b.jpg?700|}}
-These topics will be addressed at the conceptual level and also examined in specific fashion for the four physical domains (example figure below).
-{{:en:safeav:softsys:figure2c.jpg?700|}}
-**Productization Lessons and Assessments:**
-Key lessons for productization include:
-  - Engineers must understand their products operate inside a governance structure consisting of laws, regulations, and standards.
-  - In the case of autonomy, there are many historical standards, but standard development is also under development.
-  - A very key aspect of product design is the expectation function for the product. This expectation function is key to communication from a marketing perspective and also from a legal liability perspective.
-^ Domain ^ Primary Standards Body ^ Key Autonomy Standard ^
-| Ground | SAE | SAE J3016 |
-| Ground | ISO | ISO 26262, ISO 21448 |
-| Ground | UNECE | UN R157 |
-| Airborne | RTCA | DO-178C, DO-365 |
-| Airborne | FAA/EASA | UAV autonomy certification |
-| Marine | IMO | MASS autonomy levels |
-| Marine | DNV | Autonomous ship standards |
-| Space | NASA | ALFUS autonomy framework |
-| Space | CCSDS | Spacecraft autonomy protocols |
-| Cross-domain | IEEE | IEEE 7000 series |
-| Cross-domain | IEC | IEC 61508 |
-| Cross-domain | NIST | AI Risk Management Framework |
-Exercises and References
-^ Section ^ Project Title ^ Objective ^ Technical Scope ^ Deliverables ^ Learning Outcomes ^
-| 2.0 Autonomous Systems Fundamentals | Cross-Domain Autonomy Architecture Design | Understand how autonomy architectures differ across ground, airborne, marine, and space domains. | Define sensing, compute, control, and communication architecture for one system in each domain; analyze environmental constraints and failure modes. | Architecture diagrams (5–10 page report). | Understand how environment drives autonomy architecture, safety requirements, and validation strategy. |
-| 2.1 Definitions, Classification, and Levels of Autonomy | Expectation Function and Autonomy Level Classification | Learn how autonomy levels define responsibility and system capability. | Select a real-world autonomous system; classify using SAE, UAV, MASS, or ALFUS frameworks; define expectation function and responsibility allocation. | Autonomy classification report; expectation function definition; responsibility matrix. | Understand autonomy levels as technical, operational, and legal constructs. |
-| 2.2 Legal, Ethical, and Regulatory Frameworks | Autonomous System Liability Case Study | Understand relationship between validation, expectation functions, and legal liability. | Analyze a historical accident scenario; determine liability; evaluate compliance with ISO, SAE, FAA, or NASA frameworks. | Legal liability analysis report; governance compliance evaluation. | Understand how governance frameworks assign responsibility and require validation evidence. |
-| 2.3 Introduction to Validation and Verification | Operational Design Domain (ODD) and V&V Development | Learn how to construct a high-level validation plan for an autonomous system. | Define ODD; generate validation scenarios; define correctness criteria; develop validation workflow including simulation and physical tests. | Complete high-level V&V plan document; ODD, coverage, and correctness criteria. | Understand structure of validation plans and role of ODD, coverage, and correctness criteria. |
-| 2.4 Physics-Based vs Decision-Based Validation | Comparative Validation of Deterministic vs AI Systems | Understand validation complexity differences between physics-based and AI-based systems. | Construct a V&V plan for a physics-based function and also for a digital function. | Comparative report on testing methodologies. | Understand fundamental differences between validating physics-based and AI-based systems. |
-| 2.5 Validation Requirements Across Domains | Domain-Specific Validation Design | Learn how validation requirements differ across ground, airborne, marine, and space domains. | Select domain; define hazards, validation methods, certification requirements, and safety argument structure. | Domain-specific validation plan; hazard analysis; certification pathway analysis. | Understand domain-specific validation constraints and certification requirements. |
-Industries  and Companies:
-^ Type ^ Description ^ Example Players (Companies / Organizations) ^
-| Regulators & Government Agencies | Define laws, certification pathways, and operational constraints for autonomous systems across domains (ground, air, marine, space). They translate legislation into enforceable rules and approvals. | NHTSA, FAA, EASA, International Maritime Organization, NASA, ESA |
-| Standards Organizations / Industry Consortia | Develop technical standards, safety frameworks, and autonomy classification systems that regulators and industry rely on (e.g., SAE levels, ISO safety standards). | SAE International, ISO, IEEE, RTCA, ASTM |
-| Legal & Advisory Firms | Interpret liability, compliance, and regulatory frameworks; support litigation, risk assessment, and policy strategy for autonomy deployments. | Baker McKenzie, DLA Piper, Latham & Watkins |
-| Certification & Testing Authorities | Provide independent validation, certification audits, and compliance verification against safety standards (ASIL, DAL, etc.). Critical for market entry. | TÜV SÜD, UL Solutions, DNV |
-| Simulation & Digital Twin Software Providers | Provide tools for scenario-based validation, digital twins, and V&V workflows across autonomy stacks (SIL/HIL, scenario generation, formal testing). | NVIDIA (DRIVE Sim), MathWorks, Ansys, Siemens |
-| Test Track & Physical Testing Infrastructure Providers | Operate controlled environments for real-world validation (proving grounds, UAV corridors, maritime test ranges). Bridge sim-to-real validation. | American Center for Mobility, MCity, FAA UAV Test Sites |
+The chapter further highlights how software has transformed product development, supply chains, and validation practices. Cyber-physical systems are increasingly influenced by the faster-moving IT ecosystem, adopting open-source components, layered stacks, and continuous update models (e.g., software-defined vehicles). At the same time, safety standards (e.g., ISO 26262, DO-178C) and rigorous verification methods—such as hardware/software co-simulation (MIL, SIL, HIL)—have evolved to address the risks of software-driven behavior. Modern software supply chains are complex, incorporating third-party and open-source dependencies, requiring strong configuration management, traceability, and cybersecurity practices. Overall, the chapter emphasizes a fundamental shift: engineered systems are no longer hardware products with embedded software, but increasingly software platforms embodied in hardware.
+^ Stack Framework ^ Type ^ Core Covered Layers ^ Key Technologies ^ Domain Focus ^ Notes / Differentiation ^
+| ROS 2 | Open-source middleware stack | Middleware, application | DDS, nodes, topics, Gazebo, RViz | Robotics, AV | De facto R&D standard; highly modular |
+| AUTOSAR Adaptive | Automotive software platform | OS, middleware, apps | POSIX OS, SOME/IP, service-oriented | Automotive (ADAS/AV) | Designed for ISO 26262 + OTA updates |
+| AUTOSAR Classic Platform | Embedded real-time stack | HAL, RTOS, basic software | OSEK or RTOS, CAN, ECU abstraction | Automotive ECUs | Deterministic, safety-certified |
+| Apollo | Full autonomy stack | Full stack (perception → control) | Cyber RT, AI models, HD maps | Autonomous driving (L2–L4) | One of the most complete open AV stacks |
+| Autoware | Open AV stack | Full autonomy pipeline | ROS 2, perception, planning modules | Automotive, robotics | Strong academic + industry ecosystem |
+| NVIDIA DRIVE OS | Integrated platform | OS, middleware, AI runtime | CUDA, TensorRT, DriveWorks | Automotive autonomy | Tight HW/SW co-design with GPUs |
+| QNX Neutrino | RTOS middleware | OS, safety layer | POSIX RTOS, microkernel | Automotive, industrial | Strong certification (ASIL-D) |
+| VxWorks | RTOS | OS, middleware | Deterministic RTOS, ARINC653 | Aerospace, defense | Widely used in safety-critical systems |
+| PX4 Autopilot | UAV autonomy stack | Control, middleware, perception | MAVLink, EKF, control loops | UAV / drones | Industry standard for drones |
+| ArduPilot | UAV autonomy stack | Control + navigation | Mission planning, sensor fusion | UAV, marine robotics | Broad vehicle support (air/land/sea) |
+| MOOS-IvP | Marine autonomy stack | Middleware | Behavior-based robotics | Marine robotics | Optimized for low bandwidth environments |
+| DDS (Data Distribution Service) | Middleware standard | Communication layer | QoS messaging, pub-sub | Cross-domain CPS | Backbone of ROS 2 and many systems |
+| AWS RoboMaker | Cloud robotics stack | Cloud, simulation | DevOps, ROS integration | Robotics, AV | Enables CI/CD + simulation workflows |
+| Microsoft AirSim | Simulation stack | Simulation layer | Unreal Engine, physics models | UAV, AV | High-fidelity perception simulation |
+| CARLA | Simulation stack | Simulation layer | OpenDRIVE, sensors, physics | Automotive | Widely used for AV validation |
+| Gazebo | Simulation stack | Simulation integration | Physics engine, ROS integration | Robotics | Standard for ROS-based systems |

en/safeav/softsys/summary.1775633565.txt.gz · Last modified: 2026/04/08 10:32 by airi