- 博客(84)
- 资源 (6)
- 收藏
- 关注
RSS订阅
原创 手把手教你学AutoSAR - 总目录
鉴于近期较多博友问及微信群，如下可申请好友验证，请备注“autosar”，否则可能添加不通过。验证通过后，拉入讨论群。PS：本人鉴于工作事项可能不能及时回复问题，可在交流群内部和其他博友之间相互沟通交流经验。欢迎来到桃源乐游的《AutoSAR配置与实践》，以下为学习大纲，蓝色字体点击可跳转。
2023-06-07 09:37:07
6921
26
原创 手把手教你学SOME/IP「4.3.经典AutoSAR 下的SOME/IP方法论」
本文介绍了经典AutoSAR方法论下的SOME/IP设计流程。AutoSAR方法论虽存在局限性，但仍是行业标杆。其流程包括整车网络设计、ECU文件提取、算法框架搭建和代码生成等步骤。SOME/IP设计主要分为服务接口设计、服务部署、实例化和ECU抽取四个阶段。随着汽车智能化发展，传统流程面临挑战，作者呼吁行业突破创新，打造自主标准。文章对SOME/IP协议解读进行了总结，希望为读者提供帮助。
2025-10-13 23:01:28
301
原创 手把手教你学SOME/IP「4.2.经典AutoSAR下的SOME/IP-TP」
本文介绍了经典AutoSAR架构下的SOME/IP-TP通信机制。SOME/IP-TP模块通过增加SomelpTp模块实现分片传输，与PduR相连形成4个Pdu链路。发送流程采用触发式分片发送，数据仅存于Rte中避免拷贝；接收流程通过分片重组完成数据接收。该机制虽能节省资源，但会带来传输延迟和服务重用问题。建议在设计时尽量避免大包分片，若必须使用需合理规划以规避潜在问题。
2025-10-12 23:47:28
86
原创 手把手教你学SOME/IP「4.1.经典AutoSAR下的SOME/IP架构」
本文介绍了经典AutoSAR框架下的SOME/IP架构实现。在CP架构中，SOME/IP业务涉及Rte、SomeIpXf、LdCom等模块，服务发现则涉及Sd、BswM等模块。文章详细说明了各模块功能：Sd实现服务发现状态机、SomeIpXf负责序列化和包头处理、LdCom作为信号转换接口。通过业务报文和服务发现两个典型场景，阐述了数据在模块间的流转过程：从Rte调用开始，经过序列化、封装、传输等步骤最终发送；服务发现则通过BswM控制服务状态切换。文中配有架构图说明模块间的交互关系，完整呈现了AutoSA
2025-10-12 22:55:34
87
原创 手把手教你学SOME/IP「3.2.3.客户端状态机」
本文详细介绍了SOME/IP协议中客户端状态机的设计原理和工作流程。客户端状态机分为Not Requested、Searching for Service和Main三大状态，比服务端更复杂。文章首先展示了状态机概览图，然后分阶段阐述了各状态的转换逻辑：上电初始化时的条件判断、未请求服务时的Offer处理、异常状态恢复、寻找服务阶段的Find报文发送机制，以及主阶段的状态维持和异常处理。重点对比了客户端与服务端状态机的差异，特别是客户端收到Offer后直接进入Main状态的特点，解释了客户端不需要持续发送Fi
2025-10-12 16:22:49
59
原创 手把手教你学SOME/IP「3.1.3.服务发现可选项|Option」
本文介绍了SOME/IP协议中服务发现可选项（Option）的作用与分类。Option作为Entry的附加信息，主要用于传递IP和端口等通信参数。文章详细解析了Endpoint Option和Configuration Option两种类型：前者包含IPv4/IPv6地址、协议类型和端口号等固定格式字段；后者支持用户通过字符串格式自定义配置信息，采用"len+name=value"的数据结构。每种Option都通过Type字段区分类型，并规定了Length字段计算方式。文中通过具体示例说
2025-10-12 12:58:38
323
原创 手把手教你学SOME/IP「3.2.2.服务端状态机」
本文详细介绍了SOME/IP协议中服务端状态机的运行机制。状态机主要分为NotReady和Ready两大状态，其中Ready状态包含Initial Wait、Repetition和Main三个子状态。文章从初始化、状态切换、初始等待阶段、重复阶段到主阶段，逐步解析了各状态间的转换条件和行为逻辑，包括计数器设置、Offer报文发送策略等关键操作。特别说明了在不同状态下收到Find请求时的处理方式，以及配置参数对状态转换的影响。通过状态机的学习，可以深入理解SOME/IP服务发现协议的内部工作原理。
2025-10-11 00:28:49
516
原创 手把手教你学SOME/IP「3.1.2.服务发现条目|Entry」
本文介绍了SOME/IP协议中的服务发现条目（Entry）类型及其格式。Entry分为7种类型，可归纳为服务类型（EntryType1）和事件组类型（EntryType2）。EntryType1用于服务的发布与查找，包含Type、ServiceID、InstanceID、版本号及TTL等字段；EntryType2用于事件订阅管理，在EntryType1基础上增加了EventGroupID和Counter字段。文中特别说明了TTL机制的作用，它通过定时刷新报文维持服务可用性，超时则等效于停止服务。此外，Sto
2025-10-10 09:58:59
573
原创 手把手教你学SOME/IP「3.2.1.发布/订阅行为」
本文详细介绍了SOME/IP协议中的服务发现机制，重点解析了发布/订阅行为的流程。主要内容包括：1）服务发布与Method通信流程，涵盖find/offer报文交互、TTL保活机制及异常处理；2）服务订阅与Event通信流程，包括subscribe/ack报文交互和组播延迟机制；3）特殊场景如快速发送、半周期回复、重置订阅等机制。通过邮局订阅报纸的类比，帮助理解服务发现的核心原理，并强调流程图对于问题定位的重要性。文章为SOME/IP协议的工程实现提供了实用指导。
2025-10-09 23:00:34
1072
原创 手把手教你学SOME/IP「3.1.1.服务发现报文的格式」
文章摘要 本文详细解析了SOME/IP服务发现(SD)报文的格式规范。SD报文作为特殊类型的SOME/IP报文，其报文头格式与普通SOME/IP一致，但各字段值有严格限定：Message ID必须为0xFFFF8100，Request ID中ClientID固定为0x0000等。SD报文特有格式头包含RebootFlag和UnicastFlag两个标志位，其中RebootFlag与SessionID结合可判断通信方是否重启。报文主体由Entries和Options两部分组成：Entries（固定16字节）实
2025-10-09 16:50:12
699
原创 手把手教你学SOME/IP「3.0.服务发现概述」
本文介绍了SOME/IP协议中的服务发现机制。服务发现报文（SD报文）用于管理业务报文，主要实现两个功能：1）服务的发布与订阅；2）管理服务实例的运行状态。文章通过邮局卖报的类比说明两种服务发现模式：一次性购买（服务发布+主动获取）和订阅模式（服务发布+订阅+主动推送）。同时指出，当没有客户端订阅时，服务端可停止运行以节省资源。服务发现机制确保了业务报文的有效传输，并优化了系统资源使用。
2025-10-08 22:03:50
323
原创 手把手教你学SOME/IP「2.2.1.SOME/IP的传输方式」
SOME/IP的传输方式主要分为三种：TCP单播、UDP单播和UDP组播。TCP通信具有防止丢包的机制，而UDP组播类似于广播，允许所有节点接收数据。此外，文章还介绍了N-PDU传输和SOME/IP-TP传输两种特殊方式。N-PDU通过聚合多条应用层报文减少总线开销，但需权衡发送延时。SOME/IP-TP则用于处理超长数据的分片传输，通过特定的格式头和分片规则实现。文章详细说明了SOME/IP-TP的格式要求、分片示例及注意事项，包括偏移量计算、分片标志设置等关键细节。
2025-10-08 11:56:06
1048
原创 手把手教你学SOME/IP「总目录」
本文是《SOME/IP协议详解》专栏的总目录，系统介绍了SOME/IP协议的学习路径。内容分为三大部分：概述部分讲解SOME/IP的基本概念、服务化特性及车载应用；服务化通信部分详细解析协议格式、数据类型序列化等核心技术；服务发现部分涵盖报文格式、状态机等实现细节。最后还包含基于AutoSAR架构的SOME/IP实现方法。专栏通过系列文章，由浅入深地帮助读者掌握SOME/IP协议的核心知识体系。
2025-10-07 00:12:23
455
原创 手把手教你学SOME/IP「2.1.8.序列化:TLV简述|Tag Length Value」
本文介绍了SOME/IP中的TLV（Tag Length Value）序列化格式。TLV通过为每个数据添加标签头（Tag）和长度域（Length），形成类似链表的结构，便于数据管理和跳转。文章详细说明了TLV的组成，包括1bit保留位、3bit的wire type（指示长度域字节数）和12bit的data ID（需层级唯一）。通过服务接口参数和结构体成员的示例，展示了TLV的应用场景和序列化效果。使用TLV后，传输顺序可灵活调整，且能选择性序列化部分数据，但服务接口参数仍需完整传输。最后指出data ID可
2025-10-06 21:58:45
853
原创 手把手教你学SOME/IP「2.1.7•序列化:联合体|UnionVariant」
本文介绍了SOME/IP协议中联合体(UnionVariant)的序列化方法。由于联合体使用较少且易出问题，部分车厂禁止使用。联合体序列化时需选择一种类型传输，包含长度域、类型标识、数据内容和填充字节四部分。示例展示了以uint16类型传输时的数据布局，其中长度域可配置，类型标识从1开始计数，最后为满足对齐要求需填充2字节。这种设计保证了数据传输的规范性和兼容性。
2025-10-06 21:21:21
311
原创 手把手教你学SOME/IP「2.1.6•序列化:数组|Arrays」
本文介绍了SOME/IP协议中数组的序列化方法。数组分为静态长度和动态长度两类：静态数组长度固定，可选择性添加长度域；动态数组必须包含长度域，按sizeIndicator指定大小序列化。通过二维数组的示例展示了序列化布局，指出高维数组可类推处理。文章还说明数组元素不仅限于基础类型，也可以是结构体或字符串等复合类型。这种序列化方式为SOME/IP协议处理复杂数据结构提供了标准化方案。
2025-10-06 21:03:19
208
原创 手把手教你学SOME/IP 「2.1.5•序列化:字符串|Strings」
本文介绍了SOME/IP协议中字符串的序列化方法。字符串序列化支持UTF-8/16BE/16LE三种编码格式，其中UTF-8需3字节BOM和1字节终止符，UTF-16需2字节BOM和2字节终止符。字符串分为静态和动态两种形式：静态字符串通过数组定义，序列化到\0终止；动态字符串添加长度域，默认4字节。二者的主要区别在于C语言中的类型定义不同，静态为char数组，动态为包含size指示符和char数组的结构体。文中还通过"HelloWorld"示例说明了不同编码下size指示符和lengt
2025-10-06 20:21:51
845
原创 手把手教你学SOME/IP「2.1.4.序列化:结构体|Structs」
本文介绍了SOME/IP协议中结构体(Structs)的序列化规则。主要内容包括：1）结构体是由其他数据类型组合而成的复合类型，支持嵌套设计，序列化采用深度优先遍历方式；2）结构体序列化时可配置0/8/16/32位的长度域，该长度值不包含自身长度。文中通过图示展示了嵌套结构体的序列化顺序和长度域计算方法，强调序列化数据必须连续存放，不能插入无用数据。这些规则为在SOME/IP协议中实现复杂数据结构传输提供了基础。
2025-10-06 19:37:29
417
原创 手把手教你学SOME/IP「2.1.3•序列化:基础数据类型|Basic DataTypes」
摘要 本文介绍了SOME/IP协议中基础数据类型的序列化规则，列出了所有支持传输的基础数据类型。主要内容包括：基础数据类型的序列化方法说明；指出大于8bit的数据存在大小端问题；强调通信双方需协商一致Payload数据的大小端配置。文章配有数据类型表格图示，帮助读者快速理解SOME/IP基础数据类型的传输规范。
2025-10-06 10:59:00
231
原创 手把手教你学SOME/IP「2.1.2.Payload数据类型序列化」
本文介绍了SOME/IP协议中Payload数据类型的序列化规则。主要内容包括：1）SOME/IP头部采用大端字节序，而Payload可由用户自主选择大小端；2）数据对齐填充原则，SOME/IP仅对动态数据类型自动填充；3）支持的数据类型分为基础类型（如uint8）和复杂类型（如struct），特别说明string和动态数组是通过模拟实现的，不支持指针的直接序列化。文章还提到可配置TLV格式传输数据。这些规则有助于理解SOME/IP报文构造和调试。
2025-10-06 10:39:42
744
原创 手把手教你学SOME/IP「2.1.1.SOME/IP的格式头」
本文介绍了SOME/IP协议中的报文格式和传输流程。SOME/IP报文由16字节的格式头和可变长度的Payload组成，通过以太网分层封装传输。格式头包含Message ID、Length、Request ID等关键字段，用于标识服务接口、请求来源和报文类型。文章以空调控制为例说明了报文收发流程，包括序列化/反序列化处理。重点解析了Message ID的组成结构、Request ID的作用机制以及5种报文类型。最后指出Payload部分包含实际业务数据，SD服务发现报文和E2E保护也遵循相同格式头规范。
2025-10-06 09:16:45
1063
原创 手把手教你学SOME/IP「2.0.服务化通信概述」
本文介绍了SOME/IP服务化通信的核心概念，重点阐述了服务的三种接口类型：Method、Event和Field。Method实现远程方法调用，包括请求/响应和请求不响应两种形式；Event用于服务端主动通知客户端事件；Field则专注于对特定数据的读写操作。通过车载空调实例，展示了如何将功能需求转化为这三种接口设计。文章强调了这些概念在面向服务通信中的重要性，并对比了它们的使用场景和特点，为理解SOME/IP服务化通信机制提供了清晰框架。
2025-10-05 22:09:23
684
原创 手把手教你学SOME/IP「1.3.车载以太网与通信中间件」
本文探讨了车载以太网与通信中间件的发展现状。随着汽车智能化趋势，传统CAN总线已显不足，车载以太网凭借其扩展性和高带宽优势成为未来方向。在通信中间件方面，对比了SOME/IP和DDS协议：SOME/IP作为面向服务的轻量级方案更符合汽车SOA架构需求，但缺乏QoS特性；DDS虽成熟但复杂。作者认为，尽管SOME/IP存在短板，但其可定制化特点和发展潜力使其在当前更具优势。文章最后预告将开始深入解析SOME/IP协议细节。
2025-10-05 21:48:25
413
原创 手把手教你学SOME/IP「1.2.可扩展性与服务发现」
本文介绍了SOME/IP协议的可扩展性和服务发现机制。SOME/IP作为轻量级中间层协议，具有良好的平台兼容性，支持AUTOSAR AP/CP及其他平台。其服务设计扩展性体现在通信与应用同步开发、支持在线升级和动态功能扩展。通过发布/订阅机制实现动态服务管理，优化资源利用。服务发现功能用于动态查找和发布服务，管理服务状态，类似于网络管理但针对服务层面。这些特性使SOME/IP能灵活适应不同需求，支持汽车电子系统的持续演进。
2025-10-05 19:49:03
235
原创 手把手教你学SOME/IP「1.1.面向服务与面向信号」
本文对比了汽车电子系统中面向信号与面向服务两种通信方式。面向信号以CAN总线为代表，通过周期性发送固定信号实现ECU间通信，但存在资源浪费和延迟问题。面向服务采用SOME/IP协议，提供三种服务模式：事件发送（服务端主动推送）、方法调用（类似函数调用）和字段处理（结合读写与订阅功能）。面向服务通过订阅机制和按需通信，有效解决了面向信号方式的资源浪费问题，更适应现代汽车电子系统的发展需求。
2025-10-05 19:33:58
404
原创 手把手教你学SOME/IP「1.0•概述」
本文介绍了SOME/IP协议的基本概念和主要特点。SOME/IP全称为"Scalable service-Oriented MiddlewarE over IP"，是一种面向服务的车载嵌入式通信协议，支持远程过程调用、事件通知等功能。文章指出SOME/IP是AUTOSAR标准的一部分，在车载以太网架构中处于应用层位置，负责服务调度和通信封装。协议具有可扩展性强、资源消耗低、兼容性好等优势，能满足汽车电子领域对实时性、可靠性的严格要求。同时，文章也说明了SOME/IP的正确书写规范，并解释
2025-10-05 18:41:59
601
原创 手把手教你学AutoSAR（ETAS）实践篇 IPDUM模块集成说明
本文介绍了IPDUM模块的集成与测试方法。集成部分详细说明了通过补充arxml文件配置IPDU Trigger属性和PORT的步骤，包括FRAME/PDU/I-SIGNAL的触发设置、端口添加及代码生成配置。测试部分分别针对接收和发送报文进行验证，展示了接收报文字节对齐处理、动态部分选择器字段设置，以及发送报文的静态和动态布局配置，并通过示例数据验证了功能实现。整个流程从配置到测试完整覆盖了IPDUM模块的集成应用。
2025-10-04 23:19:17
93
原创 AutoSAR配置与实践（深入篇） 6.6 PNC功能介绍(下)_PNC收发流程和状态机切换详解
COM模块（Com_Mainfunction）进一步将接收到的PDU拆分为Signal，实际工程中，ERA_Rx_PDU拆分成一个ERA_Rx_Signal，EIRA_Rx_PDU拆分成一个EIRA_Rx_Signal，并将信号存储到buffer供其他应用读取；. ComM通过COM的标准接口Com_ReceiveSignal()，即可读取ERA_Rx_Signal和EIRA_Rx_Signal信号中的PNC信息.同时请求BSWM模块使能(禁止)PNC所对应的PduGroup；
2024-04-06 00:24:06
2503
3
原创 AutoSAR配置与实践（深入篇） 6.5 PNC功能介绍(上)_PNC架构、模块交互和EIRA/ERA/IRA介绍
PNC架构、模块交互和EIRA/ERA/IRA介绍PNC的交互涉及的模块较多，为了更为清晰的展示，我们通过业务划分三类：内部PN请求、外部PN请求和内外请求共用交互(相同颜色交互为一类)，
2024-04-06 00:02:43
2871
1
原创 AutoSAR配置与实践（深入篇）10.7 诊断通信管理(DCM)
诊断通信管理(DCM)主要包括三个子模块：诊断服务层(Diagnostic Service Layer，DSL)、诊断服务分配(Diagnostic Service Dispatcher, DSD)、诊断服务进程(Diagnostic Service Processing, DSP)：确定诊断数据请求和响应的数据流；监控和确保诊断请求和响应的时序，管理诊断状态（特别是诊断会话和安全状态）：接收到的诊断请求转发给数据处理器；当数据处理器触发时，通过PDUR传输诊断响应：处理实际的诊断请求。
2024-03-25 23:56:22
1038
1
原创 AutoSAR配置与实践（深入篇）10.5 CANTP 层意外N-PDU帧处理
CAN传输层对意外到达的N-PDU的行为很大程度上取决于处理N-SDU的通信方向类型。处理意外到达的N-PDU。
2024-03-20 12:24:18
585
原创 AutoSAR配置与实践（深入篇）10.4 CANTP 层主要时间参数详解（N_As/ N_ Ar/ N_ Bs/ N_ Br/ N_ Cs/ N_ Cr）
Case 3： Sender 从 收到流控帧（FC）（状态为Wait）到 收到下一个流控帧 的时间。Case 2： Sender从 发送完连续帧（CF）到 请求发送下一包连续帧（CF） 的时间。Case 2： Receiver 从 收到连续帧（CF）到 收到下一包连续帧（CF） 的时间。Case 1： Receiver 从 发送完流控帧（FC）到 收到连续帧（CF） 的时间。Case 1： Sender 从 收到流控帧（FC）到 请求发送连续帧（CF） 的时间。.req : 帧发送开始请求。
2024-03-20 12:18:12
2983
2
原创 AutoSAR配置与实践（深入篇）10.3 CANTP 传输流程和通信示例
CanlF将帧进一步转化为N-PDU（单帧(SF)/首帧(FF)/流控帧(FC)/连续帧(CF)格式）CanTP将IPDU进一步拆分成单帧(SF)/首帧(FF)/流控帧(FC)/连续帧(CF)格式。接收端回复流控报文（FC），提示发送端当前最多接收2帧CF报文，发送间隔需要为5ms。Tester(诊断上位机)通过物理总线将指令（CAN报文）发送给Can Drv。接收端发送最后一帧CF数据（少于流控参数的2帧，因为只剩余1帧）发送端依据流控参数，发送第一帧CF报文。发送端依据流控参数，发送第二帧CF报文。
2024-03-19 23:46:34
728
原创 AutoSAR配置与实践（深入篇）10.2 CANTP 单帧/首帧/流控帧/连续帧格式
> CANTP使用流控制机制来确保数据的可靠传输。接收方通过发送流控制帧来指示发送方是否可以继续发送数据。发送方会根据接收方的反馈进行数据传输，确保数据的正确到达。这种机制有助于避免接收方缓冲区溢出，保证数据传输的顺利进行。–>接收方在成功接收并组装数据后，会发送确认帧给发送方。如果发送方在规定时间内未收到确认帧，则会触发超时重传机制，重新发送未确认的数据块，以保证数据的完整性和可靠性。–> CANTP会将原始数据分割成多个小数据块，并添加相应的头部信息。
2024-03-19 23:23:32
1653
2
原创 AutoSAR配置与实践（深入篇）10.1 Diagnostics总体架构
诊断服务业务：Tester发送诊断请求指令，上传诊断应用服务处理并响应诊断服务DEM事件读写业务：应用报告DEM事件并根据需要存储NVM，诊断服务发起读取或者清除事件FIM业务: DEM将事件状态通知FIM ，应用根据FIM中的状态（条件）决定函数是否禁用->返回总目录
2024-03-17 19:07:24
678
3
原创 AutoSAR配置与实践（实践篇）12.2 Time Synchronization[Adaptive Autosar]
等等传感器捕获的数据，在算法中需要精确知道每个数据的采集时间，这样在融合时，才能确切知道使用哪个时刻的数据。每次将时基的本地实例同步到其全球时基时都会执行此操作。此外，来自time master 和 time slave 时间同步过程信息也与Validator 应用程序共享，该应用程序可以在网络中的任何位置运行，例如关于全局时间的所有者。时间网络中，应有一个Time Master，和至少一个Time Slave .其中Time Slave 根据接收到Time Master 的同步消息，进行时间对齐。
2024-01-31 09:57:17
531
原创 AutoSAR配置与实践（深入篇）10.8 UDS刷写诊断服务解析（34/36/37服务）
memoryAddress值为0x0x12345678（占4个字节，图中紫色），memorySize值为0x01234567（占4字节，图中绿色），则addressAndLengthFormatIdentifier值为0x44。该服务用于启动下载传输，作用是告知ECU准备接受数据，ECU则通过0x74 response告诉诊断仪自己是否允许传输，以及自己的接受能力是多大。：字节长度和参数格式，厂家自定义，没有定义则默认字节数据为0。：字节长度和参数格式，厂家自定义，没有定义则默认字节数据为0。
2023-11-07 23:58:26
1969
3
原创 AutoSAR配置与实践（深入篇）5.4 OS原理（下 ）- 内存保护（MPU）
ECU可能由内部模块、第三方模块等各模块集成的。需求对每个模块所定义的安全等级可能有差异，需要考虑不同安全等级的模块和代码间减少相互干扰，防止程序错误传播。可以理解为包含Task、Alarm、Counter、Schedule table、ISRs、Event等基本对象的容器，用于隔离Task/Alarm等，进行内存保护。
2023-11-01 23:49:06
3227
5
原创 AutoSAR配置与实践（深入篇）5.3 OS原理（中 ）- Task调度策略和时间保护
2. Task C在Ceiling优先级下运行时，分别产生了Task A就绪、Task B就绪、INT1中断事件，但是由于这些Task/中断优先级都小于当前Task 的Ceiling优先级。如图，当前TaskC处于运行状态，当激活TaskB进入到就绪状态时，由于TaskB优先级高于TaskC，所以TaskC被迫释放处理器控制 权，调度器 开始调度TaskB从就绪状态变为运行状态，直到TaskB运行完成之后，在调度TaskC继续运行。），Task B剥夺Task C开始执行。
2023-10-02 08:43:51
2308
3
AUTOSAR规范技术文档 - NVM中文版
2023-07-25
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人