愚公

原创 【翻译】【SOMEIP-SD】Page84 - Page86

对于Find Service Entry、Offer Service Entry、Request Service Entry，“otherserv”将被用于非SOME/IP服务实例。对于非SOME/IP协议，将使用一个特殊的Service ID，并使用Configuration Option添加更多的信息。SOME/IP服务不得在 Configuration Option 中使用字符串“otherserv”无效的条目示例： “otherserv=”无效的条目示例：“otherserv”

原创 【翻译】【SOMEIP-SD】Page79 - Page84

如果Subscribe Eventgroup Entry没有通过在 [PRS_SOMEIPSD_00130]，[PRS_SOMEIPSD_00131]，[PRS_SOMEIPSD_00832]，[PRS_SOMEIPSD_00852] 或[PRS_SOMEIPSD_00132]中规定的检查，需要发送Subscribe Eventgroup NACK Entry作为回应。如果收到一个非Subscribe Eventgroup Entry的Entry，其包含未知的Service ID该Entry应被忽略。

原创 【翻译】【SOMEIP-SD】Page74 - Page78

SD Client State Machine(Service)的初始化进入点在以下状态中。SD Client State Machine(Service) 的状态迁移如下。

原创 【翻译】【SOMEIP-SD】Page69 - Page73

条件：Timer expired [run<REPETITIONS_MAX] /send(OfferService)run++ setTimer((2ˆ run)*REPETITIONS_BASE_DELAY。条件：[REPETITIONS_MAX>0] /run=0 setTimer((2ˆ run)*REPETITIONS_BASE_DELAY)条件：receive(FindService) /waitAndSend(OfferService) ResetTimer()条件：[ifstatus!

原创 【翻译】【SOMEIP-SD】Page67 - Page69

当客户端服务实例处于 Initial Wait Phase, Repetition Phase 或 Main Phase时，服务链接关闭时，SD应进入 Down Phase，并再次进入Initial Wait Phase，当服务链接再次建立时服务仍然是可用状态。如果整个ECU被关闭，ECU上所有已提供的服务和已订阅的EventGroup都应发送Stop Offer Service entry和Stop Subscribe Eventgroup entry。为优化的目的，下面的行为应作为选项被支持。

原创 【翻译】【SOMEIP-SD】Page65 - Page66

一个服务实例的Service Discovery在发送一个消息后，应等待1*CYCLIC_OFFER_DELAY后再发送下一个消息。在Main Phase状态，如果配置了CYCLIC_Offer_DELAY，则应循环发送Offer Message。当收到 Offer entry时，其对应的Find entry应停止发送，并进入Main Phase状态。进入Main Phase提供方，在发送第一个消息前，应等待1*CYCLIC_OFFER_DELAY。

原创 【翻译】【SOMEIP-SD】Page62 - Page64

如果ClientService和ServerService分别引用相同的ClientServiceTimer和ServerServiceTimer，并且确保引用的ClientService和Server Service分别在同一时间点被请求和释放，则服务发现应使用相同的随机值。对于一个客户端为链接某个服务所创建的“客户端侧服务端实例”，当与服务端已建立链接，且服务端已可用时，“客户端侧服务端实例”应进入Initial Wait Phase状态。当服务所需的所有基础资源都已齐备查询或提供服务接口才是合适的。

原创 【RUST】学习笔记-整型

打不过就加入：C++今天已经40年，我用C++编程也已15年。虽然网上有很多看衰C++的看法，但我始终坚信C++会有它顽强的生命力。但最近看到RUST已经在Linux转正了，所以我打算加入RUST，看看它到底有何魔力。另外也是为了水点文章，获取“流量券”

原创 【Yocto】将编写软件已闭源的方式发布

Foo_rel.bb的作用是将files/rpm/Foo.rpm的安装到镜像。而Foo.rpm是从Yocto_dev的构建中拷贝出来的rpm包。也可以在Yocto_dev的Foo.bb中添加以下代码，用于将rpm文档拷贝到build/rpm目录下。将Yocto_dev中的模块Foo，已闭源的方式发布到Yocto_rel中。如果有多个rpm需要安装可以将rpm都放到一起然后将。在Yocto_dev上构建Foo。创建一个名为Foo_rel的layer，结构如下。

原创 【RUST】学习笔记-环境搭建

打不过就加入：C++今天已经40年，我用C++编程也已15年。虽然网上有很多看衰C++的看法，但我始终坚信C++会有它顽强的生命力。但最近看到RUST已经在Linux转正了，所以我打算加入RUST，看看它到底有何魔力。另外也是为了水点文章，获取“流量券”

原创 【翻译】【SOMEIP-SD】Page59 - Page62

Stop Subscribe Eventgroup Entry的各字段设置与 Subscribe Eventgroup Entry一致。除了TTL设置成0x000000。Stop Subscribe Eventgroup Entry 应该引用与其对应的Subscribe Eventgroup Entry 引用用Option。Subscribe Eventgroup Acknowledgment Entry 用于指示Subscribe Eventgroup Entry已被接收。目前支持的Entry类型概览。

原创 【翻译】【SOMEIP-SD】Page56 - Page59

如果一个没有配置UDP Endpoint 的服务端收到SubscribeEventgroup请求，且这个EventGroup也没有配置MULTICAST_THRESHOLD为1，则服务端应该应答SubscribeEventGroupNack。Subscribe Event Group引用的Endpoint Option中保存着客户端接收事件的网络地址和协议。可以是单播也可以是组播。MULTICAST_THRESHOLD 用于控制服务端最大支持单播订阅Event的数量。

原创 【翻译】【SOMEIP-SD】Page54- Page56

客户端应尽可能快的打开Subscribe Eventgroup Ack引用的Multicast Option，避免错失组播Event。Subscribe Eventgroup Entry关联的Endpoint用于服务实例UDP组播或TCP的SOME/IP时间发送。使用TCP接收Event时，客户端应该在建立Socket之后再发送 Subscribe Eventgroup Entry。注意：Subscribe Eventgroup Entry的Endpoint指的是客户端的网络地址。

原创 【翻译】【SOMEIP-SD】Page52 - Page54

使用UDP的场景，Endpoint Options中的IP地址和端口号作为Event和Notification Event发送源的地址，也作为客户端调用服务端method的地址。使用TCP的场景，客户端需要使用Endpoint Options中的IP地址和端口号与服务端建立链接，以便发出请求和接收Event和Notification Event。Endpoint Options中的IP地址和端口号也应用于Event和Notification Event的传输。允许服务端同时使用TCP和UDP。

原创 【翻译】【SOMEIP-SD】Page50 - Page52

当接收到初始化的OfferService Entry，Service ID, Instance ID, Major Version 和 Minor Version应精准匹配服务实例配置中的值，以便识别一个服务实例。当接受到后续OfferService Entry或StopOfferService Entry，其Service ID, Instance ID, Major Version 必须精准匹配初始化的OfferService entry的值，以识别一个服务实例。

原创 【翻译】【SOMEIP-SD】Page48- Page49

当接收到Find Service Entry后，应精准匹配 Service ID, Instance ID, Major Version 和 Minor Version。除非Entry中Service ID, Instance ID, Major Version 和 Minor Version没有指定明确的值，而是使用了0xFFFF、0xFFFF、0xFF、0xFFFFFFFF。在服务实例的Initial Wait Phase阶段接收到Find Service Entry应该被忽略。

原创 【Yocto】通过＜MACHINE＞.conf引入环境变量

在Yocto构建中通常会读取环境变量的需求。入：根据环境变量动态生成配置文件、根据环境变量设置编译开关等。

原创 【翻译】【SOMEIP-SD】Page46- Page48

IPv6 SD Endpoint Option是SOME/IP-SD协议中用于传输端点信息的选项，专为IPv6组播通信设计。该选项必须位于SD消息option数组首位，且不能被任何Entry引用。其包含发送方的IPv6地址、传输协议（固定为UDP）和端口号（30490），接收方需使用这些信息进行应答和通信识别。该选项类型为0x26，长度固定为0x0015，且仅适用于IPv6传输环境（IPv4接收方将忽略该选项）。规范明确要求该选项在每条SD消息中只能出现一次，并规定了严格的格式要求和处理规则。

原创 【翻译】【SOMEIP-SD】Page43- Page46

如果SD消息中包含IPv4 SD Endpoint Option，接收方应该使用该IPv4 SD Endpoint Option中的IP地址和端口号应答此消息。IPv4 SD Endpoint Option 用于发送SOME/IP-SD实例的endpoints信息，同时也预示着该option中包含的IP地址和Port号不能被其他SOMEIP服务端和客户端使用。IPv4 SD Endpoint Option 应用于指定服务发现的发送方的IPv4地址、传输层协议（ISO/OSI第4层）和端口号。

原创 01-深度学习笔记-PyTorch的核心是什么？

原创 00-深度学习笔记-模型训练流程

原创 【翻译】【SOMEIP-SD】Page41- Page43

IPv6 Multicast Option用于指定IPv6地址、传输层协议、Port号。IPv6 Multicast Option的 Port Number 应该满足以下规则。IPv6 Multicast Option 要么是服务端使用，要么是客户端使用。IPv6 Multicast Option 应使用类型0x16。

原创 【翻译】【SOMEIP-SD】Page39 - Page41

IPv4 Multicast Option 被 SubscribeEventgroup、StopSubscribeEventgroup、SubscribeEventgroupAck的Entry引用。IPv4 Multicast Option用于指定IPv4地址、传输层协议、Port号。IPv4 Multicast Option的 Port Number 应该满足以下规则。IPv4 Multicast Option 要么是服务端使用，要么是客户端使用。IPv4 Endpoint Option的格式如下。

原创 【翻译】【SOMEIP-SD】Page37 - Page39

SOME/IP-SD 使用IPv6 Endpoint Option去标记一个Endpoint。客户端在 Subscribe Eventgroup entry中使用IPv6 Endpoint Option表示一个它已经准备好可以接收的Event的Endpoint。服务端也可以在Offer Service entry中使用IPv6 Endpoint Option表示一个Event源的Endpoint。在同一ECU内部的同一个服务的服务实例应使用不同的EndPoint，不同服务之间可以共享EndPoint。

原创 【翻译】【SOMEIP-SD】Page35 - Page37

SOME/IP-SD用IPv4 Endpoint Option标记相关的endpoint。客户端准备好接收Event后，可以在Subscribe Eventgroup entry中使用IPv4 Endpoint Option标记他们想要接收的Event源。在同一个ECU内的同一个服务的不同实例应使用不同的Endpoint，不同服务之间可以使用同一个Endpoint。IPv4 Endpoint Option应指定IPv4的地址和Port号。IPv4 Endpoint Option的Type是0x04；

原创 【翻译】【SOMEIP-SD】Page33 - Page35

Load Balancing Option用于设置同一服务不同实体的优先级，以支持客户端可以动态选择服务实体。当存在多个最高优先级的服务实体时，应该按照服务实体的权重随机选择服务实体。单个服务实体被选中的概率为“自己的权重”除以“所有相同优先级实体的权重之和”Load Balancing Option 应包含类似DNS-SRV中记录的“权重”和“优先级”，“权重”和“优先级”用于在不同实体间实现负载均衡。当客户端明确指定了Service ID，则不应考虑服务实体的“权重”和“优先级”

原创 【翻译】【SOMEIP-SD】Page30 - Page33

每个键值对的后面都进跟着下一个键值对的Length字段，直到最后出现一个值为0x00的字节。多个Entry引用单一Configuration Option中的相同的“键”应被支持。每个键值对的前面都应有一个一字节的Length字段，用于标识键值对的字节长度。“键”的值不能包含“=”，“键”应该由ACSII码 (0x20-0x7E)组成。键值对中应该使用“=”（0x3D）去分割“键”和“值”键值对以“=”结束，应被视为有“键”，并有一个空“值”键值对中“键”是必须的、“值”是可选的。

原创 【翻译】【SOMEIP-SD】Page29 - Page30

在实现SOME/IP-SD时，应该支持Number of Option为0，但Option Index不为0的情况。这样的Option Run应该被忽视。如果Number of Options为0，则认为Option Run为空。没一个Option Run关联到第一个Option及Option的数量。对于空的Option Run，他的Index应设置为0。Entry使用以下字段引用Option。

原创 【翻译】【SOMEIP-SD】Page27 - Page29

存在两种entry类型：一种是针对“服务”的叫Service Entry；另一种是针对“事件组”的叫EventGroup Entry。SOME/IP-SD 中可以定义Interface的主版本和次版本，但是在SOME/IP的头中只使用主版本号。一个Service discovery消息中应支持多个entry对象。一个Service Entry的长度是16个字节，并顺序包含以下字段。消息中的entry用于服务实体的状态同步、服务的发布和订阅等功能。

原创 【翻译】【SOMEIP-SD】Page24 - Page26

所有的SOME/IP-SD消息的Reboot Flag都应被设置成1. 直到Session-ID达到最大值后被重新设置成1后，Reboot Flag应被设置成0.Entries Array和Option Array都以Length字段为开头，Length字段中的值是其数组中所有元素的字节数之和。单播的每对发送方和接受方之间，Reboot Flag和Session ID的处理应被分开。多播和单播之间，Reboot Flag和Session ID的处理应被分开。Flags的最高位被称为Reboot Flag。

原创 【翻译】【SOMEIP-SD】Page19 - Page23

如果一个服务需要在多个网络接口/地址提供服务，需要为每个网络接口/地址提供独立的服务实例。如果客户端需要在多个网络接口/地址使用服务，需要为每个网络接口/地址提供独立的客户端实例。译者理解：综上两条，对于一个网络接口/地址，服务端和客户端是1：1对应的。

原创 【翻译】【SOMEIP-SD】Page6 - Page7

本文用于说明SOME/IP-SD协议的消息格式、消息时序、语义含义。SOME/IP-SD全称为SOrientedMiddlewarEoverIPServiceDiscoveryService Discovery Protocol主要功能是在车辆以太网通信中发布服务端的能力以及约束服务端的行为。

原创 【SOMEIP】【R24-11】【需求翻译】[RS_SOMEIP_00051][2/2]

当收到新分段的Session ID与之前分段的Session ID不同时，应丢弃之前所有的旧分段，重新开始拼装新的消息。拼装后的消息应该保留消息段中Message Type的值，但需将Message Type中的TP标识设置成0。不同的被分段消息的分段顺序不需要被考虑，因为它们的分段会被分配到不同的buffer中。接受方只应拼装配置中约定的数据长度，消息中的超过该长度限制的多余数据应被抛弃。例如MS的值不是16的倍数。接受方应该基于最后收到的分段，正确处理重复的或有重叠的分段。

原创 【SOMEIP】【R24-11】【需求翻译】[RS_SOMEIP_00051][1/2]

SOME/IP协议应支持分段传输量大的数据。见： [PRS_SOMEIP_00010]见： [PRS_SOMEIP_00010]见： [PRS_SOMEIP_00010]见： [PRS_SOMEIP_00010]见： [PRS_SOMEIP_00010]见： [PRS_SOMEIP_00010]见： [PRS_SOMEIP_00010]见： [PRS_SOMEIP_00010]见： [PRS_SOMEIP_00010]见： [PRS_SOMEIP_00010]见： [PRS_SOMEIP_00010]

原创 【SOMEIP】【R24-11】【需求翻译】[RS_SOMEIP_00050][2/2]

Length字段的值需要满足[PRS_SOMEIP_00089], [PRS_SOMEIP_00090], [PRS_SOMEIP_00093], [PRS_SOMEIP_00094],[PRS_SOMEIP_00095]中的规定。Length字段需要满足 [PRS_SOMEIP_00376], [PRS_SOMEIP_00107], [PRS_SOMEIP_00377] 的要求。Length字段需要满足[PRS_SOMEIP_00119], [PRS_SOMEIP_00121]的要求。

原创 【SOMEIP】【R24-11】【需求翻译】[RS_SOMEIP_00050][1/2]

在反序列化时发现未定义的Data ID时，应根据Wire Type和Length字段跳过该数据。对于Data ID 高位应存储在第一个字节的3-0bit，低位保存在第二个字节的7-0bit。对于Wire Type为 5 6 7的数据，序列化时应忽略配置中的静态长度。一个结构体或方法参数的子数据段的Data ID应该是唯一的。见： [PRS_SOMEIP_00028]见： [PRS_SOMEIP_00028]见： [PRS_SOMEIP_00028]见： [PRS_SOMEIP_00028]

原创 【SOMEIP】【R24-11】【需求翻译】[RS_SOMEIP_00040]- [RS_SOMEIP_00042]

length字段的应参照： [PRS_SOMEIP_00079] 、 [PRS_SOMEIP_00370]当同一ECU上存在多个订阅客户端时，系统应处理通知的复制，以便在通信介质上保存传输。见：[PRS_SOMEIP_00027]见：[PRS_SOMEIP_00033]见：[PRS_SOMEIP_00039]见：[PRS_SOMEIP_00033]见：[PRS_SOMEIP_00037]见：[PRS_SOMEIP_00027]见：[PRS_SOMEIP_00027]见：[PRS_SOMEIP_00027]

原创 【SOMEIP】【R24-11】【需求翻译】[RS_SOMEIP_00038]-[RS_SOMEIP_00039]

所有的字符串数据，无论是固定长度还是非固定长度，序列化时都应该以BOM（Byte Order Mark）开头（对于UTF-8为三字节、对于UTF-16为两字节）BOM用来识别字符串的编码方式。如果接受到一个固定长度的字符串的长度小于预期，但其没有以“\0”字符结尾，反序列化应该被放弃，该消息视为malformed。如果接收到一个固定长度的字符串的长度小于预期，但其以“\0”字符结尾，这个字符串应该被接受。在定义字符串时应该指明字符串的最大长度，最大长度包含“\0”的长度。

原创 【SOMEIP】【R24-11】【需求翻译】[RS_SOMEIP_00035]-[RS_SOMEIP_00037]

对于固定长度的数组，接收到的元素的数量少于数组定义的长度时，如果数据定义了默认值则接收方将缺失的部分补充为默认值；多维数组的每个维度的子数组都必须有自己的Length字段。如果非固定长度数组的长度比预期值大（超过配置的最大值），只有配置的预期长度需要被处理，其余长度被忽略。对于固定长度的数组，接收到的元素的数量多余数组定义的长度时，对于多出的元素做忽略处理。非固定长度数组的Length字段的值是数据中Byte的数量，而不是元素的数量。非固定长度数组的内存布局，应该与固定长度数组的内存布局一致。

原创 【SOMEIP】【R24-11】【需求翻译】[RS_SOMEIP_00034]

Length字段的值小于预期的union的长度时，如果内部数据是可以被反序列化的合法数据则进行反序列化，否则放弃反序列化，将消息按照malformed message进行处理。union的Length字段的值，应包含Payload和填充数据的长度，不包含Length字段本身和Type Selector字段的长度。union类型的length字段为0bit，代表union所代表的所有数据类型的长度是相同的。如果Length字段的值长于预期的union的长度，应该按照预期的union长度进行反序列化。