德国亚马逊直邮爱他美

德国亚马逊直邮爱他美,是一条我实测成功的海淘路径。很多妈妈在选择奶粉路线时,会被真假难辨的代购、物流不稳定的海淘流程等问题纠结。于是我决定把这条自己走过的路写出来,给大家一个靠谱参考。以下内容是我从下单到收货的全过程,穿插一些实用提示与风险说明,希望能帮你把可能踩到的坑降到最低。 在进入正文之前,我先说说为什么选择德国亚马逊直邮。相比许多代购渠道,它在安全性上更有保障:亚马逊自营或平台背书,售后、物流体系更健全;而在价格方面,从德国本地站点购买时,商品会自动剔除德国本土消费税,这里就省下了一部分成本;此外,操作流程相对清晰,类似国内电商路径,新手也能快速上手。当然,这条路并不完全无风险:汇率波动、物流延误、海关抽查、退换货难题,都是需要提前有所预期的。 接下来我按时间顺序把操作流程写出来。第一个步骤是打开德国亚马逊(amazon.de):https://amazon.de 在搜索框里输入奶粉名称(如 “Aptamil Profutura 2”),在搜索结果中最好选择标注为 “Verkauf und Versand durch Amazon”(即亚马逊自营)那类商品,因为售后更可靠。我一般会避开第一行的广告位,点自然排序的结果。如果商品有多个包装规格(比如单罐、六罐、十二罐装等),我偏好原箱或大包装——这样包装更完整、运输更稳妥。 接下来点击详情页,在这里我们选择6个的选择,这款爱他美原箱是6罐,选择这个6个的很大概率直接连着原箱发,包裹就更加稳固。可看到6罐一共是155.7欧。然后点击右边的加入到购物车。 然后点击网页右上角购物车,进入购物车页面,再次确认下我们选的商品正确性,没问题的话选择继续。 现在到了付款页面了,这里需要填地址以及用于付款的信用卡信息。不知道为什么从这个页面开始网页内容变成了德语,在这里点击ändern填入中国的地址,基本上按照省市县填写拼音。在下图点击第二个红框填入信用卡信息,Mastercard或者Visa的卡号有效期卡背后的CVV。 填完这两项后会又回到这个页面,会让你选择快递。这里看到亚马逊全球标准快递(AmazonGlobal Standand)预计10月17日送达,也就是说预计耗时12天(下单日为10月5日),快递费是36.96欧。另一个亚马逊全球特快(SmazonGlobal Express-Zustellung)耗时10天,快递费是51.54欧。我选择了标快。 从上边右侧可以看到这次购物费用详单,奶粉价格是130.86欧,与我们之前看到的155.7价格低的原因是我们收货地址已经不在德国,在德国本土的消费税已经自动去除掉了。然后第二项包装快递费用是34.96欧,第三项是中国的进口税(消费税)是17.04欧。总费用是184.86欧。按照2025.10.05欧元汇率8.36换算平均一罐的费用就是8.36*184.86/6=257.57元,如果考虑到银行费用啥的大约就是265元左右到手。 点击最下边按钮就是立即购买,然后会看到成功页面,以及邮件通知。同时会有银行的扣款信息。 至此就可以坐等收货了。各种途径尝试下来,这个可能是最方便简单同时最具可靠性的方式和途径了。对代购以及国内平台不放心的朋友们,可以照着尝试尝试,如果你觉得有帮助或者说跟着教程海淘成功了,记得回来帮我点个赞啊 。

德国亚马逊直邮爱他美 Read More »

深度学习工作站系统重装步骤记录

最近需要配置一台CUDA环境深度学习工作站,打算把流程都记录一下,以防每次都得现查。 首先下载Linux镜像,我这里用的是Ubuntu24.04: https://ubuntu.com/download/desktop 然后制作一个USB镜像启动盘,这次我用的Ubuntu官网推荐的小工具,免安装并且只有3个按钮:选择镜像,选择U盘,烧录! 挺好用的推荐! balenaEtcher:https://github.com/balena-io/etcher/releases 接下来就是将BIOS选择U盘启动了,各个品牌电脑差异挺大的,按照自己实际情况去操作。然后选择全新安装Ubuntu,多数情况下直接默认选项安装就好。 系统装好后,我习惯先把当前版本的系统软件更新到最新: 当前这台工作站是公共的,需要给每个人分配一个帐号,可以在桌面环境操作,也可以通过命令完成,可以参考下边一篇记录: Ubuntu添加新用户并加入sudo组 如果工作站有中文输入需求的话,比如我目前记录这篇博文,还需要加一个中文输入法,可以看我这篇记录: Linux 安装中文输入法 接下来安装Python环境,不建议直接使用系统的Python来配置各种库,出现了问题太难修复了。建议使用Anaconda,各个环境相互不干扰。Anaconda的安装是通过官网的一个sh脚本: https://www.anaconda.com/download/success 下载后对其赋予一个执行权限,然后在终端里运行: 根据交互一步一步安装,最后一步询问要不要将Conda加入到开机初始化列表中,建议yes,不然后边每次使用Conda切环境需要手动找Anaconda安装文件夹,很麻烦。 安装完毕后,熟悉Anaconda的可以直接使用Conda来管理Python环境,若不太熟悉的话可以使用图形化的一个工具,在终端输入:anaconda-navigator 建议不要在base环境做开发,最好是每个项目有一个单独的环境,再使用conda安装pytorch,我个人没有按照Pytorch官网指导的使用pip安装,我个人经验是既然使用了Conda就尽量全Conda环境,尽量避免和pip混着用,以免一些未知的问题。在这里需要看下本机CUDA的版本,要做到Python版本、CUDA版本以及Pytorch版本相互保持一致。对应关系表在Pytorch官网可以查到。 经查询我需要安装2.5.1版本的Pytorch:conda install pytorch=2.5.1 接下来我们装个IDE,运行个实例看一看。官网下载VS Code然后使用下列命令安装: sudo dpkg -i ‘/home/v2x/Downloads/code_1.102.0-1752099874_amd64.deb’ 将自己用Anaconda建立的Python环境设为VSCode的默认解释器,按照Anaconda官方指导操作一下: https://www.anaconda.com/docs/tools/working-with-conda/ide-tutorials/vscode 之后运行一个示例程序,看下pyTorch以及CUDA是否都已经OK: 从Terminal的输出若看到True以及对应的网卡型号,那么说明基础环境已经完毕。 当需要远程连接到这台设备的话,发现SSH连不上,这是由于Ubuntu安装后默认没有sshd服务端。按照下列指导操作一下即可: Ubuntu 开启SSH连接 一些其他可能必备的工具: 最后再记录一下将U盘烧录成一个启动盘后,怎样恢复。按照通常的格式化format不管在windows还是linux都是解决不了的,可以参考下列记录解决: https://blog.shuspieler.com/1223/ 大致就这些了,祝炼丹顺利!

深度学习工作站系统重装步骤记录 Read More »

Vector DaVinci学习笔记:数据类型、接口以及SWC定义

在我学习SOME/IP过程中,涉及到了AUTOSAR常用的数据类型定义,手头上正好有Vector 的DaVinci工具,想着能否从AUTOSAR层面再递进一个层次对这个话题的学习,研究研究能否用DaVinci复刻一个之前一直用的那个SOME/IP示例数据库。 我手头有DaVinci的Developer和Configurator的License,可我没有参与具体的项目没有SIP包,所以我的电脑连Configurator装都装不上去,联系Vector售后看是否有Demo版本的SIP,至少采购DaVinci的License花了钱的至少能让我熟悉熟悉,可惜是沟通了好久无果,遗憾只能只学习学习DaVinci Developer,暂时没机会去了解Configurator了。 详细研究了一段时间Developer这个工具,我意识到我并不能从0复刻出来之前那个数据库。根据AUTOSAR体系结构的定义最高抽象为三层:应用软件层(Application Layer),运行时环境层(Runtime Environment, RTE)和在微控制器上运行的基础软件层(Basic Software, BSW)。而DaVinci Developer更多是对应用软件层做接口设计,对于系统相关的设定是不在其负责的范围内。对于我想要做的事情:设定ADAS和CAMF两个SWC并位于两个ECU或两个域中,其通过SOME/IP进行连接,传输的内容是一个多层嵌套的复杂结构体,这三件事可能只有第三个可以在Developer工具中完成,甚至ADAS和CAMF之间的接口,都体现不出来这是一个SomeIP Service,下边会具体介绍。 我的是Classic AUTOSAR工具,其主要编程语言是C,在图形化界面设计完成各个功能模块SWC后,可以生成对应的Contract Phase Headers 和Implementation Templates,从中可以看到工具将其定义的数据类型整理成C语言支持的数据结构,以及通过大量的宏定义将一些常量命名为人类友好可读的形式。还有就是工具定义了很多的接口用于SWC与之后的RTE进行功能调用数据传输。对于功能模块SWC也生成了空函数,便于后期具体逻辑填入从而实现完整的功能。 整体来说我对Vector DaVinci Developer的理解是,帮助我们在一个C语言功能开发的项目中定义头文件,通过工具的严谨性来保证代码开发方式下人类容易发生的低级错误,在此同时也会对C语言的灵活性做出一定的限制,避免一些C语言骚操作的使用不当造成未知的隐患。整体能感受到工具的目是降低数据类型定义的复杂度和出错概率,提高C语言语法使用的正确性。我们一步一步看一下工具的使用吧。 首先在DaVinci Developer中新建一个Workspace,对于要使用的AUTOSAR的版本我选择了最新的,在这儿如果是具体项目使用,就需要和整个项目所用的版本保持一致。从这个下拉框我们也可以看到,对于AUTOSAR版本的定义之前是X.Y.Z的形式,从某一个节点后改成了RYY-MM的格式,现在这种形式感觉直观了很多。 接下来我们整体看下这个工具的主界面,比较常用到的就是下边的几个框,其中1是来查看我们定义的不同元素的视图切换按钮,通过Types/Packages/Files不同维度,来看我们定义的Data Types/ Constants/ Components 等不同层级的元素。框2即为查看具体内容的地方。这次学习笔记后边大部分内容主要就是介绍这里边的各个项。 图3的框是灰的,在手册中看到这是由于我的Workspace是单独由DaVinci Developer生成而造成的,如果是配合了DaVinci Configurator的话,框3的功能既可以解锁。不过通过其他的途径我们可以使用其部分内容比如Software Design,Data Type Mapping等,后边也会有提到。 框4是的按钮可以按照AUTOSAR标准来检查我们的设计和配置是否有错误。可以帮我们做一些标准一致性上的检查,还是很实用的。框5是看我们鼠标当下选中的元素的具体属性信息的。 模仿之前数据库我计划是设计ADAS/CAMF两个SWC,之间的数据接口使用的TrafficSignDetection结构体。我额外设计了一个叫做Preprocessing的SWC,来模拟一个DistanceToSign的输入。在DaVinci Developer设计SWC时候有Composition Component Types 和Application Component Types两个概念,主要的区别是Composition可以理解成功能整体,而Application是组成整体的最小模块。Composition可以包含其他的Composition和Application,而Application是最小逻辑单位了不能再继续拆分。在这里我配置了一个ADAS_CAMF_Composition,我们假设这即为摄像头自动驾驶系统,然后这个系统由三个子模块组成:ADAS, CAMF 和Preprocessing,如下图。 双击我们新建的Composition,即进入了Software Design的界面了。可以看下图我这里的结构,一个Composition下挂3个Application,选中顶层Composition可在中间Interface Graphic界面看整个功能的对外接口,当前我的示例中输入为一个DistanceToSign_Application_Port_Interface_Comp_Input, 输出为DistanceToSign_Application_Port_Interface_Comp_Output。 切换在Structure Graphic视图,可以直观看到整个功能里边的模块是信号怎么流传的。我的学习示例中整个功能唯一的输入先送到Preprocessing模块,然后再原封不动透传到ADAS模块,假设再ASAS里我们做了一些处理,然后输出一个TrafficSignDetection结构体到CAMF,再在CAMF里边做一些处理,输出一个DistanceToSign作为整个功能的输出。 接下来从0开始看下这个例程中数据类型是怎么配置的。以Speed和signDistance为例,下边截图是对于Speed的Unit、CompuMethod 以及 Int To Phys

Vector DaVinci学习笔记:数据类型、接口以及SWC定义 Read More »

德国中国(新生儿)疫苗对比

要准备着给即将到来的新生儿打疫苗,了解到有很多必须接种的有一些是自费接种的,搞不明白哪些是真的推荐自费的哪些是医院用来营收的,我想着对比一下德国和中国的疫苗免疫体系,计划从中找点启发。 首先是中国儿童免疫程序表: 接下来是德国的儿童免疫程序表: ✅ 共同接种的疫苗项目(中德都有) 疾病 中文疫苗名称 英文缩写(中国) 德国对应名称 说明 乙肝 乙肝疫苗 HepB Hepatitis B 接种时间略有差异,中国更早 卡介苗(结核) 卡介苗 BCG – 德国不常规接种,仅推荐给高风险人群(非普种) 脊髓灰质炎 脊灰灭活疫苗、脊灰减毒活疫苗 IPV, bOPV Poliomyelitis 德国只用灭活疫苗(IPV) 百日咳 百白破疫苗(含) DTaP Pertussis 同为联合疫苗成分 白喉 百白破疫苗 / 白破疫苗 DTaP / DT Diphtherie 同上 破伤风 百白破疫苗 / 白破疫苗 DTaP / DT Tetanus 同上 麻疹 麻风腮三联疫苗 MMR Masern 接种时间略有不同

德国中国(新生儿)疫苗对比 Read More »

在德国补打疫苗推荐

下边这一段是之前朋友想我咨询在德国需要补哪些疫苗我给到的回复,当时研究了好久自己补了很多,所以时不时就有朋友问,之前我就把这一段发给他们,现在感觉可以记录在这里,有需要在德国补打疫苗的可以参考一下: 疫苗推荐更新:刚刚和医生详细沟通了一下,并且拿我自己总结的小时候打过的疫苗让医生看看哪些需要补打,很多错过的就错过了,主要是针对婴幼儿时期容易生的病。剩下的还有这些: DPPT(破伤风、白喉、骨髓灰质炎和百日咳): 每十年补打一Hepatitis A&B(甲肝乙肝): 每十年补打一次Influenza(流感): 每年一针所以小时候应该都打过,只是国内不知道要不要每十年补打,我身边人包括自己做到这一要求的不多。所以可以和医生讲价情况补打一次MMR(麻疹、腮腺炎、风疹):我上次没问医生也没主动提这个疫苗,今天问了下医生说小时候没接种啊!刚刚查了一下这个疫苗中国2008年是加入的免疫计划,所以2008年之前出生的可能没有接种过。而这个疫苗在德国是儿童时期强制接种的。医生说现在很多公共场合区域就需有对这个疫苗的接种证明。我今天医生这个需要再打,医生说以前接种过得找接种的地方去查记录,没有记录的就要重新接种,医生讲,医生看记录时要注意,一些疫苗的接种需要有 MMR 接种证明才能上岗。于是今天被捅住打了一针 MMR。 注意:DPPT 需要打一针,Hepatitis 需要打 3针,第一针第二针间隔1个月,第二针第三针间隔6个月。另外不同疫苗之间最短间隔 4周,如果不同疫苗间隔少于4周,需要医生评估。像今天我打 MMR 同周上次甲肝乙肝刚过去 2周,违背了疫苗注射的推荐间隔4周的要求,就是护士拿着接种单去找医生做了二次确认才来给我注射。 最终版总结:DPPT(破伤风、白喉、骨髓灰质炎和百日咳):每十年补打一针,Hepatitis A&B(甲肝乙肝):每十年补打一次,三针Influenza(流感):每年,一针MMR(麻疹、腮腺炎、风疹):2008年前出生,在德国生活推荐补打,2针 Reference:https://www.bundesgesundheitsministerium.de/themen/praevention/impfungen/schutzimpfungen.html http://www.caixin.com/2020-01-04/101500751.html http://www.chinacdc.cn/jkzt/ymyjz/zswd_10960/201904/t20190426_201664.html https://www.chinacdc.cn/jkyj/mygh02/jswj_mygh/myfw_mygh/202505/U020250528538419216264.pdf

在德国补打疫苗推荐 Read More »

SomeIP学习笔记:使用CANoe调试/仿真SomeIP服务

从上一篇文章(SomeIP学习笔记:基础知识)的介绍可看出SOME/IP标准预先定义了很多很实用的数据类型,可在实际项目中可能处于兼容性的需求,不完全依照上边数据类型原始定义使用,可能会结合着信号矩阵有进一步的定义,比如说有Offset和Scale的设置等。 接下来记录一下用CANoe怎样调试或者模拟AUTOSAR环境下的SOME/IP通信,在这里我使用的是CANoe SP5的一个SOME/IP例程:Basic AUTOSAR SOME/IP Event,如下图。 这个样例是使用Simulation Setup模式结合了一个ARXML创建的,已经有了很好的Pannel,对于我们学习Simulation消息订阅很方便。在下边两个框CAMF和ADAS,我们可以点击Enable Service或者Subscribe Service, 从上边的Trace窗口可以看到对应的服务端、客户端相应的Offer Service、Find Service、Subscribe Event group以及Stop Subscribe Event group的报文。 这个报文其实现原理主要依赖了三大块:CANoe的SOME/IP协议栈、示例ARXML数据库以及几个节点的CAPL代码。 其中示例ARXML数据库定义了一个服务端(Provider: CAMF)和一个客户端(Consumer: ADAS),规定了其支持的服务类型:即一个名叫ADASDisplayInfo的Event 事件通知,然后这个事件传输的变量叫做DetectedTrafficSign,类似于一个结构体,里边有SignType、DistanceToSign以及Realiabiliy变量,以及每个变量的更加细致的定义。 然后CAPL代码一方面实现了对于变量的填充,另一方面调用CANoe的SOME/IP协议栈进行Event Notification的发送以及SD服务发现事件订阅的过程。 最后SOME/IP协议栈提供了底层的交互支持,以及对CAPL的API调用的支持,从而非常简单实现服务发现订阅以及发送接收。 在这个例程默认的界面下,可以尝试点击那些按钮来从trace看服务端怎样发送报文Offer一个Service,以及客户端怎样发送报文Find 一个Service,以及服务订阅上后ACK是什么样,还有到了真正Event Notification的报文是什么样。这对于基础的SOME/IP报文熟悉还是非常有帮助的。 而截至目前所能模拟的通信都很依赖ARXML对于Service的定义,我想记录的更多的是对于自定义SOME/IP的学习以及调试方法。以这个ARXML中的服务为例,首先我们需要将其转换成CANoe可编辑的模式,使用CANoe自带的小工具将其转换成可编辑的数据库格式vCODM。 接下来就用不到这个例程了,我们把刚刚转换号的vCODM数据库存到某个文件夹,然后以此为例记录一下怎样使用CANoe的SOME/IP协议栈来自定义数据库模拟一个服务。 我们新建一个空的工程,使用Communication Setup模式,然后在红框1 和红框2处倒入刚才我们转换完成的数据。红框3我们下一步再点击,接下来将两个节点设置成仿真模式,以及将Real Bus换成Simulated Bus模式,现在运行一下看看效果。 点击运行后到Trace窗口看到,并没有像Simulation Setup 的例程那样有Service Offer、Service Find 以及Subscribe信息。 这个区别的主要原因是例程中数据库并没有开启服务发现SD协议,而例程中通过CAPL命令实现了Service Offer以及Service Subscribe。由于我们新建的没有这些脚本,所以从Trace来看并没有任何SOME/IP相关的数据。 在一开始我们了解到SOME/IP有一个SD服务发现的协议,在这儿没有起作用,是因为在数据库中,示例数据库这个设置处于关闭状态。我们在刚才按钮3的地方进入数据库编辑页面,然后将Discovery Technology协议从None 改成SOME/IP Service Discovery,这样子协议栈就会自动执行服务发现过程,保存运行然后我们再观察Trace窗口,有时候需要重新加载一下数据库才能生效。 现在看到已经有了Service Offer、Service Find、Subscribe Event group

SomeIP学习笔记:使用CANoe调试/仿真SomeIP服务 Read More »

SomeIP学习笔记:基础知识

在整车功能开发以及调试过程中,ECU与ECU之间使用车载以太网的比例越来越多,所以区别于之前的CAN总线报文的,对于以太网数据包的抓取和分析越来越普及了,而其中又绕不开SOME/IP,每一个搞过车载功能开发都或多或少接触过或者使用过SOME/IP。我在了解这个协议过程中走了不少弯路,后来发现并没那么复杂,于是打算把自己的心得记录下来。 主要从3个角度记录我所学习的SOME/IP,首先是一些基本的知识,其次是怎样用Vector CANoe来调试一个结合了AUTOSAR通信,包括怎样在CANoe里边调整数据库实现自定义调试;最后做一个实践,使用开源的SOME/IP协议栈vsomeip,来和我们CANoe的SOME/IP协议栈做一个真实的通信。 SOME/IP基础知识 SOME/IP是基于TCP/UDP/IP协议之上的应用层协议,很像网络开发中前后端交互的HTTP的方式。如果之前做过前后端的开发,对于客户端和服务器的连接有一定的知识储备,那么在了解SOME/IP的过程中会觉得很简单的。SOME/IP依托于TCP或UDP,所有的数据都是作为TCP/UDP的Payload通过IP协议进行传输。可以理解成在Payload中又做了进一步的切分,并且比特位以及长度做了事先约定,例如下图中的前16个Bit固定为Service ID,紧接着的16个Bit为Method ID或者Event ID。 目前网络中常见的SOME/IP学习路径和学习资料,包括我之前看的一些,大多是在CAN总线技术路线以及实现方式的基础上介绍SOME/IP的特点以及技术细节的,很多从以太网IP以及UDP和TCP开始讲起,然后再说到SOME/IP的各种Header头部还有服务订阅等等内容,这样的一个学习路径,非常容易把很多的类似的概念参合到一起,比如IP层、UDP、TCP以及SOME/IP都有Header头部,IPv4和IPv6头部又不一样,TCP的三次握手四次挥手和SOME/IP的Subscribe订阅以及UDP和Notification,太太太容易混淆了。可能看了好久还觉得云里雾里,觉得这个太高深了,其实真的SOME/IP没啥,将其理解成ECU之间的HTTP类似协议,下层依赖的TCP/UDP和电脑手机服务器用的没有任何区别,明白这个就已经学会了一大半。关于车载以太网和普通以太网的区别,我在另外一个学习记录贴中有记录,一句话总结就是物理层数据链路有区别,到了IP层以上就完全一样了。 不过从另外一个角度也可以理解,很多汽车软件的开发人员是从传统技术栈比如CAN总线时代过来的,对于以太网的了解不像互联网人那样深入,所以有一定的需求再详细了解一些IP/TCP/UDP的知识。我的建议是将这两部分分开学习,先回顾一下计算机网络,七层协议啥的,再了解一个应用层协议比如HTTP,最后再详细学习SOME/IP,绝对会事半功倍,发现真的好简单,半天时间SOME/IP入门足够。 另外在车载应用开发中,SOME/IP的Payload部分填充,考虑到和其他ECU以及功能的兼容性问题,会使用AUTOSAR的规则定义方式,这和CAN总线的Frame帧非常的像。在CAN总线Data Field数据场一次最多传输8字节,通常会把这对应的64个比特拆分成传输数据的最小量,比如一个布尔型只分配1个比特,然后一个0-255的Uint8只分配8个比特,总共8字节64比特能拆分成很多个Signal信号,从而有限的资源传输更多数据,各个Bit对应的Signal信号长度以及数据类型的记录成一个表格,即得到了CAN总线数据库DBC。在车载SOME/IP开发中Payload部分多数情况下也沿用了类似的思路,所以在Payload部分解析也需要一些额外的信号矩阵,结合了SOME/IP支持的数据结构和AUTOSAR数据结构,就能组合出很多复杂的结构体,实现更多上层应用间的数据传输。 这样的实现方式也可以很好的复用迁移传统汽车行业稳定成熟的软件解决方案,在必要的情况下,只需要在传输层做一些技术更新,核心逻辑不需要任何变动,从而降低潜在的风险。但是这一块是互联网人来做汽车软件的话,可能就不是很熟悉了,尤其对于不常见的Bit位的数据拆分,再结合这大端小端数据类型,还有信号矩阵有Scale放大缩小以及Offset偏移,八成互联网人转过来的开发第一次会搞错。建议之前对于汽车总线了解较少的开发人员可以系统学习一下CAN总线以及结合项目了解一下AUTOSAR信号矩阵,可以避免很多低级的错误。 传统车载网络CAN总线在面向信号的数据传输中,发送方会根据自身需求(如数值更新或变更时)主动发送信息,而无需考虑网络中是否有接收方当下需要这些数据。与之不同的是面向服务的数据传输模式即发送方仅当网络中至少存在一个接收方需要该数据时才会进行传输。这种方式的优势在于避免了不必要的数据对网络及所有连接节点造成的负载。因此,面向服务的数据传输要求服务器必须通过某种方式获知哪些接收方正在等待其数据。在SOA架构中,服务是构成系统的基本单元,它代表了系统中的某个功能或操作。服务通过明确的接口与外界进行交互,实现了功能的封装和重用。SOA架构的核心就是服务,它通过将应用程序划分为一系列的服务来降低系统的复杂度,提高系统的灵活性和可维护性。在SOA中,服务是通过其接口被定义和访问。接口是服务与外界交互的桥梁,它定义了服务的输入、输出和行为规范。在SOA架构中,以太网通信作为服务的传输载体,负责在不同的ECU或服务之间传递数据和信息,根据AUTOSAR平台的规范与推荐,一般选择以太网应用层协议SOME/IP协议或者DDS协议作为跨域通信协议。 在SOME/IP协议中,服务接口被明确划分为三种类型: Event、Field、Method,每种类型都服务于不同的通信需求。 Event and Field Notification 服务器基于活跃订阅发送的内容可呈现两种格式:事件通知(Event Notification)和字段通知(Field Notification)。这两种格式的共同特性是事件驱动生成机制,但其数据结构存在本质差异: 事件通知Event:采用自包含的静态快照形式,其字段填充的属性仅反映事件触发时的瞬时状态,与历史事件无任何关联 字段通知Field:包含具有时序关联性的动态值,除当前值外还隐含历史状态。因此字段可扩展为包含Getter/Setter方法,允许客户端对目标内容进行读写操作。 需要特别说明的是,在SOME/IP协议中,事件总是以事件组(Event group)的形式进行组织,客户端仅能订阅整个事件组,而无法单独订阅组内某个特定事件。Field的Setter/Getter 方法遵循请求/响应(REQUEST/RESPONSE)模式,变更通知则通过事件机制实现,所有订阅操作都需通过SOME/IP服务发现(SOME/IP Service Discovery)协议完成。 Method 另一种数据交换方式是通过方法调用(Method Call)实现信息传递。客户端通过发起远程过程调用(Remote Procedure Call, RPC),触发目标服务器上的函数执行。具体流程如下: 调用过程:客户端通过网络发送请求来调用服务器函数,该请求可包含作为参数传递至被调用方法的数据; 响应机制:服务器执行函数后,可能通过响应消息向客户端返回执行结果。 需注意,当客户端主动调用函数时,通常意味着需要获取返回数据,通常被称作RR模式(Method Request with Response),但服务器方法也可能不返回任何值(Void类型),常被称作FF模式(Method Fire & Forget),此时客户端在确认方法被成功调用后即完成整个流程。 Service Discovery 为了让客户端能够获知当前可用的服务,SOME/IP-SD(服务发现协议)提供了两种动态服务发现机制: 服务提供(Offer Service): 服务器通过该机制向网络宣告其提供的所有可用服务 每个设备通过组播(multicast)方式广播消息 消息内容包含该设备提供的所有服务列表 传输层采用UDP协议 服务查找(Find

SomeIP学习笔记:基础知识 Read More »

华硕路由器梅林固件设置IPv6防火墙

之前在家里设置了一个影音库,与公网通过IPv6连接,实现pt上传积分和从外部对家里的多媒体资源访问的需求,我的家庭影音库。当时对于家庭路由器防火墙的设置,是通过静态唯一地址设置的,后来发现一个问题,在路由器重新拨号,或者时间够久的情况下中国移动端会改变IPv6前缀,这就出现了一个问题,我们通过上篇文章操作的防火墙设置,其中的IP地址已经不正确了,造成pt上传赚积分也赚不到了,从外网也连不到我家里的NAS媒体资源。所以使用了半年多以来,几乎每一两个月都得重新设置一遍IPv6防火墙,挺烦的。 于是我查好资料看有没有通过类似于通配符的方式设置防火墙,这样子及时前缀变了,但是依旧能映射到唯一的硬件设备。还真有解决方案,不过由于我是使用的梅林版的华硕路由器,有一些查出来的对原版梅林固件好使的方法,在我这里不适用,我找啊找终于到到适合我的方式。如果也有小伙伴使用华硕路由器结合梅林固件,需要在动态IPv6的情况下设置防火墙,可以参考一下我的方法。 首先IPv6设置里边对于子网的IP选择Stateless,这样子路由器给设备分配的IP后边4段会根据路由器的Mac地址结EUI-64算法生成唯一设备后缀地址。然后我们在NAS设备里看下实际分配的地址,然后在华硕路由器里边IPv6防火墙本地 IP 地址要按 0::a:b:c:b/0::ffff:ffff:ffff:ffff 的格式进行填写,其中 a:b:c:d 部分替换为实际设备 IP 地址的后四段。端口部分可以一次填入多个,使用英文逗号分隔,例如:5000,5001,5006,5999,8096,16681。 查询各种帖子了解到,对于华硕路由器,可以设置为 ::a:b:c:d/::ffff:ffff:ffff:ffff格式。也有帖子提到对于梅林改版固件,不能留空双冒号,即为0:0:0:0:a:b:c:d/0:0:0:0:ffff:ffff:ffff:ffff 格式。这几种方式在我这里会使iptable配置报错,造成公网的IP地址丢失,从而整体IPv6都不可用了。有帖子说这是特定版本梅林的Bug,第一位的0不能省略,确实在我这里实践好使。 设置后保存重启我们试一下,路由器拿到了新的前缀,然后pt工具也可以看到与公网联通了,上传通路正常。 觉得有帮助的小伙伴来点个赞啊。   Reference: https://post.smzdm.com/p/a2xx273n/ https://www.right.com.cn/forum/thread-8417643-1-1.html https://www.cnblogs.com/osnosn/p/11781359.html https://post.smzdm.com/p/a25gmdoq/ https://zhuanlan.zhihu.com/p/665423070 https://www.zhihu.com/question/363164098 https://www.right.com.cn/FORUM/thread-4108336-1-1.html  

华硕路由器梅林固件设置IPv6防火墙 Read More »

车联网C-V2X学习笔记

V2X是什么 参与V2X量产相关的项目于有一段时间了,终于终于现在对这个领域有了一个轮廓性的了解,真是不容易,功能虽小,但是将其用到量产,涉及到的知识却非常的广泛,趁着现在还没忘掉,打算沉淀成一篇笔记。 V2X,全称Vehicle-to-Everything,中文意思是“车对一切”。它是一种让车辆能够与周围环境中的各种实体进行数据交换的通信技术,是万物互联在汽车出行领域的拓展。这些实体包括: 其他车辆(V2V):车辆之间可以互相通信,共享速度、位置、转向等信息,提前预警潜在的碰撞风险,提前做行驶规划,让车与车有了直接的交互。 行人(V2P):车辆可以通过感知到附近的行人,尤其是盲区的行人非机动车,并采取相应的避让措施。 道路设施(V2I):车辆可以直接与周边交通信号灯、路标等基础设施进行通信,获取实时准确的交通信息。 网络(V2N):车辆可以连接到互联网,获取天气、路况以及更远处交通事故等信息等信息。 形象地说,常规的ADAS是给车辆装上了眼睛,让车辆自己可以观察周边环境进行一定程度的自动驾驶。而V2X就像给车辆装上了一张嘴巴和一对耳朵,可以说出自己的情况,以及听到周边车辆他们遇到的事情,这让更高级级别的自动驾驶成为可能。 V2X技术路线 目前,V2X主要有两大技术路线:DSRC和C-V2X: DSRC(IEEE 802.11p)技术:由IEEE主导标准制定,提供短距离无线传输技术,以车车和车路通信为主要方式。 C-V2X技术:包括LTE-V2X和NR-V2X,由3GPP主导标准制定。C-V2X是将蜂窝通信技术和直通通信技术有机结合得车联网无线通信技术,同时支持车-车直通通信和蜂窝通信两种方式,支持车车、车路、车人以及车网等各类应用。 简单的说,对于车联网这个新的需求,尤其直通技术上,DSRC是将WiFi协议魔改过来得技术,而C-V2X是将无线通信LTE以及4G魔改来的技术。虽技术严谨路线有所区别,但是要解决的遇到的问题是大致一致的,IEEE 802.11p和C-V2X以及NR-V2X主要体现在无线接入技术的不同上。在协议其中C-V2X尽量重用蜂窝系统已有的上层协议,将研究重点聚焦于接入层的物理层和媒体接入技术。DSRC包括两类,用于ETC的DSRC和基于802.11pde DSRC,两者是不同的技术。两种技术路线相似的网络层可支持IP协议栈,同时考虑IP协议栈的开销以及低时延传输要求,,也可采用非IP传输支持上层应用。在《蜂窝车联网(C-V2X)》一书中有一个图表,很清晰对比出DSRC、LTE-V2X以及NR-V2X协议层的区别和联系。 适用范围和趋势 DSRC仅在部分早期部署国家(如日本、欧洲)保留残余应用,而LTE-V2X在中、美、韩等国已成主导技术。C-V2X(尤其是LTE/NR-V2X)凭借技术演进、政策支持和商业成熟度,将在不久的将来全面取代DSRC,成为智能交通和自动驾驶的核心通信标准。 关键技术标准 对于LTE-V2X有一个标准对其做出了总体技术要求:《YD_T 3400-2018 基于LTE的车联网无线通信技术 总体技术要求》,从很大范围的对其总体业务、系统架构以及功能需求做了一些规范性要求。比如说:有效通信距离、移动速度、通信时延、传输可靠性、覆盖要求、消息发送频率要求、消息大小要求、架构模型、接口、功能实体、高层功能、无线功能、标识以及功能描述和消息流等。 附录还有基于LTE车联网应用场景及需求部分,对于一些常见场景,可以了解其场景描述、预期效果和需求分析等内容。主要包含这些场景: 安全应用: 前方静止车辆告警 前方慢速车辆告警 紧急电子刹车灯告警 逆向超车提示 逆向行驶告警 换道决策辅助提示 交叉口防撞提示 异常车辆提示 道路危险状况提示 道路施工告警指示 协作式自动巡航控制 协作式高速公路车辆自动系统(直线) 前向碰撞预警 汇入主路辅助/碰撞告警 紧急车辆提示 非机动车横穿预警/行人横穿预警 道路湿滑/危险路段提醒 左转辅助/告警 闯红灯(/黄灯)告警 交通效率提升 道路限速提示 交通信号灯提醒 交通信息及路线推荐 增强得路线指引和导航 专用道路管理 限行管理 车载标识 车速引导 信息娱乐服务 服务信息公告

车联网C-V2X学习笔记 Read More »