This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |||
| en:safeav:hw [2026/06/16 10:08] – [Hardware and Sensing Technologies] pczekalski | en: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, |
| + | 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, | ||
| + | Signal flow follows this chain in a continuous loop (figure {{ref> | ||
| + | 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> | ||
| + | {{ : | ||
| + | < | ||
| + | </figure> | ||