Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
en:safeav:hw [2026/06/16 10:08] – [Hardware and Sensing Technologies] pczekalskien:safeav:hw [2026/06/16 10:21] (current) – [Hardware Architecture and Signal Flow] pczekalski
Line 43: Line 43:
  
 ===== Hardware Architecture and Signal Flow ===== ===== Hardware Architecture and Signal Flow =====
-<todo @rczyba>todo</todo>+Autonomous systems—UAVs, UGVs, USVs, and a spacecraft—rest on the same principle: they must sense their environment, decide, and act without a human in the loop. This sense–compute–actuate cycle is realised in hardware, and understanding that hardware, along with how signals move through it, is the starting point for any verification and validation (V&V) effort. 
 +A generic autonomous platform can be divided into five interacting blocks. The sensing layer converts physical phenomena into electrical signals: cameras, lidar, and radar perceive the surroundings, while inertial measurement units (IMUs), GNSS receivers, and similar devices track the system's own motion and state. The processing layer conditions these signals, digitises them, and runs perception, sensor fusion, and decision algorithms on CPUs, GPUs, FPGAs, or dedicated accelerators. The actuation layer turns decisions back into motion through motors, thrusters, or control surfaces. Supporting all three are the power subsystem, which stores and distributes energy, and the communication and timing infrastructure—the buses, networks, and clocks that keep the parts synchronised. 
 +Signal flow follows this chain in a continuous loop (figure {{ref>hwsignalflow1}}). A physical quantity is captured by a transducer, conditioned and converted to digital form, fused with estimates of the world and the vehicle, compared against a goal, and turned into commands that drive an actuator. The resulting motion changes the environment, which the sensors observe again, closing the feedback loop. 
 +The same architecture recurs across domains with different parts. In a drone, IMU, barometer, and GNSS data are sent to a flight controller that commands the speed controllers and rotors. In a car, cameras, radar, and lidar feed a compute platform that drives steering, braking, and throttle control over CAN or automotive Ethernet. A spacecraft pairs star trackers and sun sensors with a radiation-hardened computer to command reaction wheels and thrusters over buses such as MIL-STD-1553 or SpaceWire. A marine vehicle uses sonar, Doppler velocity logs, and inertial navigation to drive thrusters and fins. 
 +This architecture is also a map of where things can go wrong. Every sensor, processor, interface, and actuator is a potential source of fault, and the signal path determines how a fault propagates toward unsafe behaviour. Effective hardware V&V therefore follows the signal flow end-to-end, verifying each block, each interface, and the timing that binds them—the task taken up in the chapters that follow. 
 + 
 +<figure hwsignalflow1> 
 +{{ :en:safeav:autonomous_hardware_signal_flow_loop.svg |Signal flow loop in autonomous systems}} 
 +<caption>Signal flow loop in autonomous systems</caption> 
 +</figure>
en/safeav/hw.txt · Last modified: by pczekalski
CC Attribution-Share Alike 4.0 International
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0