技术方案对比维度 第1篇
依据本技术方案我们完成了C-V2X T-Box 原型机的开发：
（1）硬件印刷电路板（Printed Circuit Board，PCB）电子设计与制板；
（2）软件进行了重构，继承了4G T-Box 的全部功能，新加入了V2X 应用程序与engine。
实车实验部署了原型机进行了V2X 应用场景验证，出现如下问题：
（1）起初实车测试验证中发现HV 与RV 距离超过50 米时，数据丢包率非常高。通过对于基于车辆移动性V2X 链路连通性能分析[4]：空旷的测试路面，没有遮挡物，直线视野非常好，车流速率，车辆速度，车辆密度等影响链路连通性能的条件都非常好，那么理论上V2X 链路连通性能应该是最佳状态。实际的丢包率高反应了超过50 米时V2X 链路连通性能就非常差，分析问题应该是V2X模组无线信道衰落引起的。继续跟进V2X 模组收发天线发射功率，发现硬件板卡天线附近有磁珠影响天线发射功率。移除磁珠后，继续进行实验测试，HV 与RV 直线距离可达200 米。问题得以解决。
（2）V2X 模组工作半小时后，容易出现大量的丢包情况。问题（1）已经排除出了天线收发功率衰减引起的问题，那么现在出现的问题应该是V2X 模组长时间运行后，HV 与RV 之间通信信道稳定性与路径路由长时间运行失效，以至于不能持续长时间支持V2X 海量数据收发引起的。基于此，我们请模组供应商对V2X 路由协议进行了优化处理，用链路连接失效时间（LET）和有效带宽建立双重约束，通过选用LET 构建最优通信路由路径[5]。后续测试验证中，超过两小时的行车测试未出现大量丢包现象，实际证明问题得以优化解决。
技术方案对比维度 第2篇
V2X 场景的实现，是需要高精度GPS 模组支持：定位精度要求是纳米级，且上报GPS 的频率是10 赫兹（Hertz，Hz）。
根据本案硬件设计，如图3 硬件框图所示：MPU 外接高精度GPS 模组，GPS 模组通过UART 把美国国家海洋电子协会 （National Marine Electronics Association，NMEA）数据发送到MPU，另外有秒脉冲（Pulse Per Second，PPS）接入MPU 中断处理信号。
图5：V2X 数据发送流程
图6：V2X 数据接收流程
图7：FCW 处理流程
GPS 模组定位后：
（1）以每秒10Hz 频率发送NMEA 数据到MPU，满足V2X场景每秒接收10 次NMEA 数据；
（2）GPS 触发PPS 信号对MPU 进行精确授时处理，精度可达纳秒级。
MPU 模组内嵌直接通信（PC5）协议栈，软件开发工具（Software Develop Kit，SDK）提供有PC5 协议栈收发API，因此V2X 应用程序可以很方便地实现V2X 数据的收发处理。
在《合作式智能运输系统车用通信系统应用层及应用数据交互标准》里定义了V2X 数据的收发时采用抽象语法标记（Abstract Syntax Notation One，）进行编解码器对原始数据进行处理，V2X 应用程序要将 编解码器集成到程序里来使用。
图5 显示了本案发送V2X 数据的处理流程。
说明：
（1）图5 V2X 数据发送流程是实现一次完整的V2X 消息集合（MessageSet）数据包发送过程，实际运行中由GPS 接收NMEA回调函数触发该流程。因为GPS 上报NMEA 数据频率是10Hz，所以当GPS 模组定位后每秒会触发10 次该流程。即本案T-Box 每秒会使用该发送流程向周围其他V2X 设备发送10 帧本设备V2X MessageSet 数据。
（2）V2X 应用程序在启用数据发送流程前，首先要注册高精度GPS 接收NMEA 数据回调函数，这样当高精度GPS 定位后就会向V2X 应用程序发送收到GPS 有效数据信号，即本流程过程调用步骤2。
（3）过程调用步骤3，这里是采集CAN 数据。在从MCU采集CAN 信号时，需使用本案式（2）、式（3）和式（4）完成MCU 的大端CAN 数据格式向MPU 的小端CAN 数据格式转换。
（4）图5 V2X 数据发送流程步骤7，这里是将本设备V2X MessageSet 数据发送给V2X 应用程序引擎（如图4，V2X engine）。V2X 应用程序引擎会将本设备数据与收到的其他设备的数据进行运算处理，来实现各种V2X 场景应用。
图6 显示了本案接收V2X 数据的处理流程。
说明：
（1）图6 V2X 数据接收流程是实现一次完整的V2X MessageSet 数据包接收过程，实际运行中由PC5 注册回调函数触发。
（2）V2X 应用程序在启用数据接收流程前，首先要注册PC5注册回调函数，这样当V2X 模组收到其他设备的MessageSet 数据立即触发V2X 应用程序调用数据接收流程完成数据接收处理，即本流程过程调用2。
（3）图6 V2X 数据接收流程步骤4，这里是将其他设备V2X MessageSet 数据发送给V2X 应用程序引擎。这样V2X 应用程序引擎会将本设备数据与收到的其他设备的数据进行运算处理，来实现各种V2X 场景应用。
V2X 应用程序引擎体现在本案软件设计方案如图4 所示。其主要功能是：
（1）实时采集本设备的MessageSet 数据，实时采集其他设备MessageSet 数据；
（2）快速运算MessageSet 数据，计算结果若有V2X 场景如前向碰撞预警、交叉路口碰撞预警等场景）定义的结果出现，则向V2X 应用程序发送相关的预警信号，再由V2X 应用程序将预警结果通知到相关的设备人机交互界面（Human Machine Interface，HMI）（如车机、仪表等）对车辆驾驶员进行碰撞预警；
那V2X 应用程序引擎的运算能力的主要性能指标，在标准里定义其延时要＜100 毫秒（millisecond，ms）。
接下来的章节以前向碰撞预警（Forward Collision Warning，FCW）为例。
FCW 计算公式
FCW 的定义为：主车（Host Vehicle，HV）在车道上行驶，与正前方车道的远车（Remote Vehicle，RV）存在追尾碰撞危险时，FCW 应用将对HV 驾驶员进行预警。
接下来本案以FCW 场景为例，主要论述一下提高V2X 应用程序引擎的运算能力的设计要点。
首先定义计算公式如下。
式中，Mh 是HV 本次HV 的MessageSet, Mr 是RV 的MessageSet。输出值Mfcw 是有前车碰撞预警的MessageSet。
参与FCW 运算的MessageSet 主要数据如表2 所示。
使用表2 里的数据项来描述Mh、Mr 其公式如下：
接下来要定义一个满足FCW 的数据集合，如下。
对于“式（5）”使用“式（6）”、“式（7）”和“式（8）”进行推导如下：
首先计算出ΔM。
接着计算Mfcw。
V2X 应用程序引擎采集到有效HV 和RV 数据后，调用“式（5）”就可以完成本次前向预警计算：
（1）若Mfcw=[0, 0, 0, 0]则表示HV 与RV 处于安全状态；
（2）=Mr 则表示HV 将要追尾RV，此时V2X 应用程序引擎应发出预警信号到应用程序进一步处理。
FCW 处理流程
V2X 程序引擎使用“式（5）”进行数据处理流程如图7。
FCW 计算公式效率
对于“式（5）”、“式（6）”、“式（7）”和“式（8）”我们做了模拟代码，并在C-V2X 5G T-Box 原型机上进行了实际运行验证，其统计结果如表3 所示CPU 消耗clock。
从表3 可以看出执行1 次“式（5）”消耗时间不超过1ms，那么在标准定义的最大延时＜100ms 内，V2X 应用程序engine 可以完整的处理100 笔以上FCW 数据计算运算。目前这样的结果满足标准定义以及与实车运行的需要。
FCW 计算公式注解
对于“式（8）”中取值范围说明：
（1）δt,因为标准定义FCW 最大延时＜100ms，所以对于参与运算的两笔数据时刻差＜100ms 内算有效值，否则对于V2X 应用程序引擎来说认为数据无效；
（2）δlng,通常取-50 米到50 米的经度度值，这里计算方法以上海地区为例：上海位于北纬30 度处，纬线周长为34668千米，即1 米对应的经度度值等于360 度/34668 千米，即1 米≈ 度。
（3）δlat,通常取-50 米到50 米的纬度度值，这里计算方法：经线周长为40076 千米，即1 米对应的维度度值等于360 度/40076千米，即1 米≈ 度。
（4）δv,HV 与RV 车速比较计算δv：
=0 表示vh=vr
＜0 表示vh＜vr
＞0 表示vh＞vr。
本案覆盖了标准定义的17 种应用场景，如表4 所示。
对于表4，其中：
（1）1-12 项为安全应用场景。
（2）13-16 项为效率应用场景。
（3）17 项为信息服务应用场景。
技术方案对比维度 第3篇
针对不同的受众，有不同的分析图，但是，也是层层深入的；大概有下面的 8个维度
用于描述系统的参与者与功能用例间的关系，反映系统的最终需求和交互设计，通常由用例图表示；
场景分析图的受众：外部的技术或非技术人员，包括团队内部或外部的开发人员或运维人员
用于描述系统软件功能拆解后的组件关系，组件约束和边界，反映系统整体组成与系统如何构建的过程，通常 子系统的 线框图表示。
用于描述要我们要构建的系统是什么，子系统直接的依赖关系是什么，用户是谁，需要如何融入已有的IT环境。
系统依赖分析图的受众：外部的技术或非技术人员，包括团队内部或外部的开发人员或运维人员
子系统依赖 是 系统依赖图里 ，对待建设的子系统做了一个内部依赖关系展开分析，
子系统依赖分析 主要用来描述子软件系统的内部的依赖关系，分析系统中的职责是如何分布的，子系统是如何交互的。
子系统依赖分析的受众：外部的技术或非技术人员，包括团队内部或外部的开发人员或运维人员
组件架构图是把针对某个子系统 进行组件设计、模块设计，组件架构图 用于 子系统 的模块关系，介绍 子系统由哪些组件/服务组成，了组件之间的关系和依赖，为软件开发如何分解交付提供了框架。
组件架构图受众：主要是给内部开发人员看的。组件架构图的作用：为代码的组织和模块架构，提供支撑
从编码的维度来说，组件内部，很多模块。模块架构分析 ，是对组件的进一步 深入分析。
模块架构分析用于描述模块划分和组成,
模块架构分析可以细化到内部包的组成设计，服务于开发人员，反映系统开发实施过程。
用于描述系统模块内部的的通信时序,数据的输入输出,反映系统的功能流程与数据流程,、
通常由时序图和流程图表示。
用于描述系统软件到物理硬件的映射关系,反映出系统的组件是如何部署到一组可计算机器节点上，用于指导软件系统的部署实施过程。
对于程序员来说，最常用的是这三种架构图， 系统架构分析：通常用于整体描述系统所包含的组件 组件架构图：通常用于模块设计 逻辑架构视图 ：通常用于开发小组内部讨论具体的复杂的开发流程；
技术方案对比维度 第4篇
多宠识别技术通过多维度生物特征与行为模式分析，实现精准个体区分。其核心技术架构分为三部分：
轻量级检测模型：边缘计算芯片部署于本地设备（如摄像头），实时过滤无宠物画面，降低算力消耗。
云端特征提取模型：基于云端自研大模型，提取宠物脸部、鼻纹、体型等高精度特征，支持复杂场景下的多宠区分。
向量检索：通过预训练模型生成特征向量，与数据库秒级匹配。
多模态语义分析：当面部信息缺失时，结合品种、毛色、步态等特征，通过大模型完成识别。
自适应抽帧算法：根据宠物运动状态调整视频抽帧频率（快速移动时密集抽帧，静态时降低频率）。
反馈学习闭环：用户手动纠正后，系统自动更新模型参数，持续优化识别能力。
技术方案对比维度 第5篇
需求，很重要！技术人员千万不要忽略需求，因为不管你的技术有多牛逼，都一定为需求服务的，不管这个需求是技术需求，还是业务需求，一定都是要为需求服务。而需求，就是你这个技术方案的起点，技术方案一切都是围绕需求来设计，当然，这个需求可以是当下的需求，也可以包含未来潜在的需求。
只有把需求介绍清楚之后，大家才能知道你方案设计里面的所有设计和对应的折中点是否可行，也才能比较好的去评审你的方案。
业务需求就是你这个业务具体要做的事情，包括但不限于：
我们做需求的时候，对于技术人员，不能只看业务需求，业务需求可能是项目管理人员，也可能是产品人员提出来的，他们只会重点关注业务的可行性，只会关注业务的逻辑。但是技术人员，要从这个业务需求里面考虑清楚我们满足这个业务之下的性能需求点，比如我做一个秒杀活动，如果你不考虑性能，可能活动一上来，服务就挂掉了。性能需求包括但不限于：