华测导航嵌入式软件秋招二面：多传感器系统设计

《面试题目》

1. 编队系统中，前车和后车通常如何通信？通信距离如何确定？
2. 多模态感知系统的整体方案应该如何设计？
3. 从系统架构上看，一个复杂嵌入式系统会涉及多进程和多线程吗？多进程如何部署？
4. 多进程中的共享内存应该如何设计，才能避免数据竞争？
5. 时间基准是如何实现的？同步机制如何设计？
6. 时间源通常来自哪里？不同时间源有什么区别？
7. 请先做一下自我介绍。
8. 你为什么每次实习都三个月？
9. 你的职业规划是什么？
10. 你研究生的研究方向是什么？

《参考解析》

前后车通信：先看链路预算，再定协议

车与车之间的通信方式要按车辆间距、遮挡情况、实时性和可靠性要求来选：车队内部的低延迟控制信息用专用无线链路或局域网，跨区域传输才考虑蜂窝网络，短距低功耗组网可以用 802.15.4 类协议。通信距离不能只看理论参数，还要算天线增益、发射功率、频段、遮挡、多径和行驶环境。协议层面至少要带设备编号、序列号、时间戳、消息类型、载荷长度和 CRC16，关键控制数据再加确认、超时重传和失联保护。后车超时后不能无限等待，要进入降级模式：减速、保持安全距离甚至停止运行——这一条在面试里必须主动说，它体现的是失效安全（fail-safe）意识。

时间基准：墙上时钟和单调时钟要分清

系统里至少要区分两类时钟：墙上时钟（CLOCK_REALTIME）表示真实日期时间，可以靠 NTP、PTP 或 GNSS 校准，适合打时间戳和跨设备对时；单调时钟（CLOCK_MONOTONIC / CLOCK_MONOTONIC_RAW）不会因为校时倒退或跳变，适合算超时、周期和耗时。用墙上时钟量耗时是常见 bug，一次 NTP 校时就能让差值变成负数或异常大的值；测耗时用 clock_gettime(CLOCK_MONOTONIC_RAW, ...) 取前后两个 timespec 再换算成纳秒。时间源方面，CPU 单调时钟适合算间隔但不代表真实日期，RTC 断电后仍能计时但精度和温漂有限，GNSS 能提供较准的绝对时间但在室内、隧道、遮挡环境下可能不可用，NTP 部署便宜但精度受网络延迟和抖动影响，PTP 配合硬件时间戳才能到亚微秒级。实际系统通常设计主备时间源，比如优先 GNSS、失锁后切 PTP 或本地保持（holdover）。

高精度同步：PTP 怎么工作，精度目标怎么定

PTP（IEEE 1588）靠主从报文交换估计时钟偏移和链路延迟：主时钟周期发送 Sync 并记录发送时间戳，从时钟记录接收时间，必要时用 Follow_Up 携带精确发送时间戳，再通过 Delay_Req / Delay_Resp 测出往返延迟，据此做偏移补偿或频率调整。要拿到亚微秒精度，硬件时间戳（MAC/PHY 打戳）几乎是必需的——纯软件打戳会被协议栈排队和中断延迟污染。工程上还要处理交换机是否支持透明时钟和边界时钟、路径是否非对称、GNSS 失锁后的保持策略，以及校时过程中的单调性保护。最后要明确精度目标：普通状态监测毫秒级够用，音视频同步要亚毫秒，雷达与相机的空间融合要求更高，分布式控制还要考虑网络抖动和最坏延迟——目标不同，选型和成本差一个数量级。

共享内存：难的不是映射，是协议

共享内存只保证多个进程能访问同一块物理内存，不提供任何一致性保证，所以设计重点在协议。固定大小的数据可以用环形缓冲区，配进程间信号量、PTHREAD_PROCESS_SHARED 互斥锁或 futex 做同步；大图像和音视频帧更适合「控制区 + 数据区」分离，控制结构里放版本、索引、长度、时间戳、状态和校验和，数据区放真正的帧，消费者按索引去取。结构体本身要小心：32 位和 64 位平台布局不同，字节序、对齐和编译器填充都会让两端解释不一致，所以要用固定宽度类型、显式对齐，必要时加魔数和版本号；进程异常退出后锁可能停在持有状态，需要 owner 记录或超时恢复机制。最关键的一点是不要让消费者「看到一个有效标志就读」——生产者写入过程中标志也可能已经置位，应该用序列号协议：写入前把序列号置为奇数、写完置为偶数，消费者读到前后一致且为偶数才认为数据完整；或者用双缓冲，写完再原子切换指向的槽位。

多模态融合：按时间戳对齐，而不是按到达顺序

多模态系统通常接入相机、激光雷达、毫米波雷达、IMU 等，架构分层是采集（驱动与设备状态）→ 时间同步（统一时间基准）→ 预处理（去噪、坐标变换、畸变校正、格式转换）→ 特征提取 → 融合决策（数据级、特征级、决策级）→ 结果输出。最容易犯的错是按数据到达顺序直接融合：相机帧在 t1 曝光、经过驱动和传输 t2 才到，如果拿 t2 当采集时间，高速运动场景下就会产生明显的空间偏差，必须用硬件时间戳或同步触发把各传感器对齐到同一时间基准，并在融合前做运动补偿。系统还要设计降级策略：某个传感器短时异常时降低其权重，长时间失效则切换到其他传感器组合，同时向上层报告当前感知能力已经下降，而不是继续输出看起来正常的融合结果。

多进程与多线程：按故障域划分，再谈部署

复杂嵌入式系统通常两者都用。多进程用来隔离不同功能和不同可靠性等级的模块——设备管理、算法推理、远程升级、日志服务各自独立，某个算法进程崩溃不会拖垮设备管理；进程内再用多线程做并行（采集、解析、处理、发送），线程共享内存通信快，但锁和对象生命周期要严格管理。部署一般交给 systemd、自研监管进程或容器，配置项包括启动顺序、依赖关系、自动重启、资源限制、日志输出、健康检查、优雅退出和看门狗策略。要注意「进程还在」不等于「服务还活着」：假死（不再处理心跳、消费不动队列）也要能触发重启，所以健康检查要有业务级探针；重启还要有退避策略，避免崩溃-重启风暴。