1. 最大的挑战是人才
传统主机厂的
EEA工程师不熟悉软件。主机厂的传统是自己定义通信矩阵，交给各个
tier1去落实DBC，然后把各个供应商交付的
ECU通过
CAN总线拼装起来，信号调通了，开发就完成了。这个过程不需要软件架构师的参与，因为基于信号的整车电子电气架构本身是一个非常清晰的架构，清晰到使用者只需要定义好每个组件的接口（DBC）就够了。而且这个架构也足够硬，平常我们讲软件总线，毕竟只是个比喻，软的，不但可以绕开，实在不行还可以修改。但是CAN总线可是实打实的硬件，ISO定义成什么样就得是什么样，一点变通的余地都没有。这种情况下，EEA工程师得不到软件方面的训练。
tier1软件工程师懂软件，也有过硬的硬实时系统编程素养。但是ECU软件功能相对单一，结构复杂度较低，而往
SOA转型需要站在整车架构思考问题。
ICT行业培养了大量软件工程师。车上的嵌入式软件的技术栈和通信设备软件契合度非常高，各大车厂往SOA转型的时候，都从通信设备行业招募了不少软件工程师。通信设备行业的优势是软件规模足够大，通常比车载软件复杂，但缺点是通信设备最多算软实时系统，从业者缺乏开发硬实时系统的方法论。
所以所有工程师都有一个学习培养的过程，提前认识到这一点，有意识的开展针对性的培训，可以少走不少弯路。
2. 问题的关键不是面向信号还是面向服务，而是设计是否匹配需求
一个真实的例子，某新势力在着手上SOA的时候，相当部分来自传统主机厂的架构师认为既然好不容易上了SOA，可以用
RPC按需调用服务，那就没必要再沿用CAN总线时代的cyclic消息了。但是RPC命令丢失怎么办？提供服务的ECU因为故障下线了怎么办？最后发现，在汽车这个环境里面，单纯的RPC其实只能用在不牵涉功能安全的地方。
做设计实事求是很重要，不能执着于技术名词，否则可能会跑偏。
3.SOA架构需要专人看护
软件就像人体，人体随着吃喝拉撒而不断衰老，软件架构如果没人看护，也会随着一次一次的修改而·不断退化。软件工程史上有很多优美的架构，但是没法阻止工程师在这些架构上堆出屎山一样的代码，有时候纯粹是因为无知，有时候是为了规避局部风险，最后都以复杂度膨胀到无法维护而告终。一个典型的纯电车上通常有300+左右的服务，一个人已经看护不过来，需要分解到领域分头管理。
4. 以太网不是瓶颈
首先是bps（带宽）。除了激光雷达等视觉传感器，相比于以太网动辄百兆，千兆的带宽来说，车上的带宽需求其实相当低。整车感知和控制信息的数量却决于传感器和执行器的数量，这些器件并不会因为向SOA转型而变多。我们统计某辆旗舰车上面所有用CAN_FD承载的通信负担加起来不超过40M bps，转向以太网以后因为帧结构的原因载荷效率会小不少，但是不会超过10倍，而以太网交换机的交换能力动辄几十个G，实际统计下来负载最重的MCU的以太网出口带宽没超过5Mbps。
其次是PPS（本质是中断发生率）。报文数量影响中断数量，进而影响MCU处理能力。由于中断数量等于外部事件的数量。执行器和传感器的数量和工作方式没有变化，事件的数量也不会变多。
5.不用急着上TSN
虽然新能源车都使用了支持TSN的网络硬件，但是据我所知，大部分厂商其实只启用了时间同步协议，因为ADAS在做计算时需要知道各个传感器采集数据的时刻。还有部分厂商在旗舰车型里面启用了802.1CB以支持冗余。TSN中其他和流量传输相关的特性，比如802.1Qbv, 802.1Qbu，802.1Qcr等，其实用得并不多。因为就现阶段车载以太网负载而言，启用基于P bit的优先级调度就能解决通信的实时性问题
当然，现在不着急上TSN，是因为支持的功能还是原来就有的功能，并不是说将来也不用上。既然TSN在这里了，必然有人去思考引入以前的通信条件无法支撑的业务，比如反应更加灵敏的主动悬架，可能需要顶在四个轮子上的电机更加协调一致的调节底盘高度，这个时候802.1Qbv和802.1Qbu可能就能发挥用处了。
6.网络确实需要改造
首先，链路层需要改造。比如交换机和网卡至少需要启用基于P bit的优先级调度。
其次，协议栈也需要改造。首先要对不同优先级的报文进行空间和时间上的隔离。传统TCP/IP host协议栈平等对待所有报文，体现在空间上就是共享报文缓冲区。可以想象诊断任务的优先级比运动控制任务的优先级要低，如果来了大量的诊断报文，但是因为诊断应用被运动控制任务抢占，导致它不能及时消费掉挤压在协议栈中的报文，最后缓冲区耗尽，运动控制相关的关键报文就只好丢弃。体现在时间上，不同优先级的报文最好承载在对应优先级的task里面，避免低优先级报文挤占高优先级报文的时间。
其次是协议栈的单槽队列改造。传统的TCP/IP协议栈，哪怕是UDP报文，能不丢就尽量不丢，所以协议栈内部存在若干排队环节。但是对车载感知业务来说，依次处理排队的数据是没有意义的。如果新数据到了，老数据就应该忽略。所以，我们需要针对UDP对协议栈进行改造，以支持单槽队列，以新盖旧。
7.
SOME/IP还是
DDS?
我的推荐是SOME/IP。
我在另一篇文章
《车载网络的本质思考》中提到，车载网络的关键业务是状态同步，DDS无疑就是冲着数据同步这个使命去的。但是为什么还是推荐SOME/IP呢？且不说footprint，但说复杂性，DDS为了支持各种数据同步应场景，把自己做得太灵活了，光QoS就有10+种配置，灵活性的另外一张面孔就是复杂性，如果不是老手，很容易被这些灵活性搞糊涂。而SOME/IP的三个核心概念：event, field和method，可以简单理解为就是针对汽车这个特定场景封装好的DDS，状态同步用field，事件用event，远程调用用method，几乎找不到这三个概念覆盖不了的场景。使用SOME/IP的另一个好处是它被
AUTOSAR收录了，有完备的工具链支撑它的开发和调试。
这段文字发布几天之后，关于SOME/IP和DDS的选择，我又有些犹豫了。或许在当前这个转型阶段，选择DDS更为合适。
如果选择SOME/IP，来自其他领域的软件工程师很容易把注意力放到event和method上面去，因为on changed 的event和on demand method所代表的编程范式和软实时或者非实时领域的范式是一致的，很容易错过切换设计思路的机会，在不该使用这两个手段的时候误用；而来自汽车电子领域的朋友，如果对通信（包括中间件在内的stack）本质上的不可靠性认识不够，则很容易受不了method的直接性的诱惑，在本该使用event和field的地方误用method。
而DDS充分体现了车载通信的状态同步的本质，和汽车电子承载的业务有天然的匹配性，其以数据同步为一等要务的内核，使得你但凡想偏离这个本质做点别的，比如RPC，会显得十分别扭。来自传统汽车电子的朋友很容把它和基于信号的编程范式匹配起来，而来自其他领域的软件工程师，也可以被迫意识到问题域的本质发生了变化，需要切换到以数据为中心的思维方式上来。
关于博主
an actually real engineer
通信工程专业毕业,7年开发经验
技术栈:
精通c/c++
精通golang
熟悉常见的脚本,js,lua,python,php
熟悉电路基础,嵌入式,单片机
耕耘领域:
服务端开发
嵌入式开发
>gin接口代码CURD生成工具
sql ddl to struct and markdown,将sql表自动化生成代码内对应的结构体和markdown表格格式,节省宝贵的时间。
qt .ui文件转css文件
duilib xml 自动生成绑定控件代码
协议调试器
基于lua虚拟机的的协议调试器软件 支持的协议有:
串口
tcp客户端/服务端
udp 组播/udp节点
tcp websocket 客户端/服务端
软件界面
使用例子: 通过脚本来获得接收到的数据并写入文件和展示在界面上
下载地址和源码
webrtc easy demo
webrtc c++ native 库 demo 实现功能:
基于QT
webrtc摄像头/桌面捕获功能
opengl渲染/多播放窗格管理
janus meeting room
下载地址和源码
wifi,蓝牙 - 无线开关
实现功能:
通过wifi/蓝牙实现远程开关电器或者其他电子设备
电路原理图:
实物图:
深度学习验证工具
虚拟示波器
硬件实物图:
实现原理
基本性能
采集频率: 取决于外部adc模块和ebaz4205矿板的以太网接口速率,最高可以达到100M/8 约为12.5MPS
上位机实现功能: 采集,显示波形,存储wave文件。
参数可运行时配置
上位机:
显示缓冲区大小可调
刷新率可调节
触发显示刷新可调节
又一个modbus调试工具
最近混迹物联网企业,发现目前缺少一个简易可用的modbus调试工具,本软件旨在为开发者提供一个简单modbus测试工具。
主打一个代码简单易修改。
特点:
1. 基于QT5
2. 基于libmodbus
3. 三方库完全跨平台,linux/windows。
开源plutosdr 板卡
1. 完全开源
2. 提高固件定制服务
3. 硬件售价450 手焊产量有线
测试数据
内部DDS回环测试
接收测试
外部发送500MHZ FM波形
matlab测试
2TRX版本
大部分plutosdr应用场景都是讲plutosdr板卡作为射频收发器来使用。
实际上plutosdr板卡本身运行linux 操作系统。是具有一定脱机运算的能力。
对于一些微型频谱检测,简单射频信号收发等应用完全可以将应用层直接实现在板卡上
相较于通过网卡或者USB口传输具有更稳定,带宽更高等优点。
本开源板卡由于了SD卡启动,较原版pluto支持了自定义启动应用的功能。
提供了应用层开发SDK(编译器，buildroot文件系统)。
通过usb连接电脑,经过RNDIS驱动可以近似为通过网卡连接
(支持固件的开发定制)。
二次开发例子
```
all:
arm-linux-gnueabihf-gcc -mfloat-abi=hard --sysroot=/root/v0.32_2trx/buildroot/output/staging -std=gnu99 -g -o pluto_stream ad9361-iiostream.c -lpthread -liio -lm -Wall -Wextra -lrt
clean:
rm pluto_stream
版面分析即分析出图片内的具体文件元素,如文档标题,文档内容,文档页码等,本工具基于cnstd模型