Software foundations, domain context and standards

Software emerged when hardware platforms became programmable after fabrication. In early electronic systems, functionality was largely embodied in physical circuits; modifying behaviour often required redesigning hardware. Programmable processors, configurable hardware and programmable logic changed that relationship. They allowed functions to be expressed as instructions, configurations or hardware descriptions that could be changed without manufacturing a new physical device.

This separation between physical implementation and functional behaviour made modern autonomy possible. A vehicle, aircraft, vessel or spacecraft can reuse hardware while evolving control logic, diagnostics, communications and user-facing services. However, programmability also changes the nature of failure. Hardware failures are often random or wear-related, while software failures are usually systematic: the system faithfully executes the logic that engineers specified, implemented or configured, even when that logic is incomplete or unsafe.

The shift toward software-defined products extends this logic. Software is no longer a fixed firmware layer burned into a device at manufacturing time. It is part of an evolving ecosystem of operating systems, libraries, middleware, AI models, communication services and update mechanisms. For autonomous systems, this creates both opportunity and risk: capability can improve after deployment, but the assurance argument must remain valid after every change.

The introduction of software followed different timelines across ground, airborne, marine and space systems. In ground vehicles, production software first became prominent in engine control and later expanded into braking, steering, airbags, infotainment, advanced driver assistance and software-defined vehicle platforms. In airborne systems, software entered flight-critical roles earlier because digital avionics and fly-by-wire control demanded rigorous assurance. In marine systems, software first supported navigation, propulsion monitoring and integrated bridge functions, with autonomy and remote operation now increasing the importance of software safety. In space systems, onboard software has always been central because communication delays and inaccessible hardware require autonomous guidance, telemetry, fault management and mission control.

Across these domains, the long-term pattern is consistent. Software moved from supporting narrow control or advisory tasks to becoming the coordinating layer for sensing, decision-making, communication and actuation. This shift is one of the main enablers of autonomy. It also means that the safety of the physical system increasingly depends on software architecture, middleware timing, configuration discipline, update governance and the quality of verification evidence.

Software safety standards emerged because software risk cannot be managed only through hardware reliability analysis. IEC 61508 provides a broad functional-safety reference for programmable electronic systems. ISO 26262 adapts these concepts to road vehicles and introduces ASIL-based development rigor. DO-178C structures airborne software assurance through development assurance levels, objective satisfaction, verification independence and coverage expectations. ISO/IEC/IEEE 12207 defines software lifecycle processes, while ISO/IEC/IEEE 828 addresses configuration management.

These standards align naturally with the V-model because they emphasize requirements, architecture, implementation, verification evidence, configuration control and release discipline. Nevertheless, standards do not guarantee safety by themselves. They specify process expectations and evidence categories, but the engineering team must still justify why the software architecture, operational assumptions, middleware behaviour, AI data and residual risks are acceptable for the intended domain.

Ground systems, especially road vehicles and mobile robots, are increasingly shaped by the software-defined vehicle paradigm. Traditional vehicle architectures used many function-specific electronic control units connected by relatively low-bandwidth networks. Newer architectures consolidate functions into centralized or zonal compute platforms, add high-bandwidth Ethernet and support over-the-air updates. This enables faster innovation but increases integration risk, because a change in a shared middleware service or operating-system configuration can affect many features at once.

Airborne systems illustrate a different pattern. Software is often organised around strict partitioning, independence and development assurance. A low-criticality application must not interfere with a flight-critical function through memory corruption, CPU starvation, timing interference or unsafe message exchange. Middleware and operating-system services must therefore support temporal and spatial isolation, robust health monitoring and documented configuration.

Marine systems face long vessel lifecycles, mixed equipment suppliers and intermittent connectivity. Autonomy software may need to integrate legacy navigation equipment, radar, sonar, propulsion systems, remote-operation links and shore services. Because retrofits are common, configuration records and equipment compatibility become central to safety. Space systems add another set of constraints: autonomy must tolerate communication delay, limited repair options, radiation effects, power limitations and mission-specific payload behaviour.