====== Summary ======

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.

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.

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.

Assessment:

^ # ^ Assessment Title ^ Description (Project / Report) ^ Learning Objectives ^
| 1 | Evolution of Programmable Systems | Write a report tracing the evolution from fixed-function hardware to programmable systems (configuration, FPGA, microprocessors) and the abstraction of software as an abstraction. Include historical milestones and examples. | Understand the transition from hardware-centric to software-defined systems. Explain key programming paradigms (configuration, assembly, high-level programming). Analyze the role of abstraction architecture (e.g., system stack). |
| 2 | Cyber-Physical Software Stack Analysis | Develop a structured report analyzing a real-world CPS (e.g., automotive ADAS, UAV, or spacecraft). Map its software stack (HAL, RTOS, middleware, applications) and explain how each layer contributes to overall system functionality. | Identify layers in CPS software architectures. Explain the role of RTOS, middleware, and HAL. Analyze real-time and safety constraints in system design. |
| 3 | IT vs CPS Supply Chain Comparison Study | Produce a comparative analysis of hardware and software supply chains in IT vs CPS, with focus on lifecycle management, dependencies, and update strategies. Include risks and trade-offs. | Compare IT and CPS development ecosystems. Evaluate the impact of “innovation cycles” in CPS (cost, obsolescence, certification). Assess risks (safety, cybersecurity) and benefits (flexibility, innovation). |
| 4 | Safety Verification and Validation Framework | Write a report comparing software validation approaches in IT and CPS, focusing on simulation/emulation (MIL, SIL, HIL) and safety standards (e.g., ISO 26262, DO-178C). Include a case study. | Understand verification vs validation in different domains. Explain simulation/emulation methods in CPS. Analyze how safety standards shape software development. |
| 5 | Software-Defined System Proposal | Develop a conceptual design for a “software-defined” system (e.g., vehicle, drone, or marine system). Describe architecture, update model (OTA), software stack, and lifecycle management approach. | Apply concepts of software-defined systems. Design layered, modular architectures. Integrate lifecycle, update, and maintainability considerations. |

^ 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 |