2024/3/17周报

摘要

本周阅读了Transformer的开山之作《Attention Is All You Need》。Transformer完全基于注意力机制,完全免除了递归和卷积。在两个机器翻译任务上的实验表明,Transformer模型在质量上是上级的,同时具有更好的并行性,并且训练时间也更少。此外,还对Transformer模型的原理进行了深入学习和研究。

Abstract

Transformer’s pioneering work , Attention Is All You Need is readed this week. Transformer is completely based on attention mechanism, which completely eliminates recursion and convolution. Experiments on two machine translation tasks show that the Transformer model is superior in quality, with better parallelism and less training time. In addition, the principle of Transformer model is deeply studied.

文献阅读

题目

Attention Is All You Need

引言

递归神经网络LSTM和GRU一直是序列建模和转导问题(如语言建模和机器翻译)的最新方法。这些递归模型生成隐藏状态ht的序列,作为前一个隐藏状态ht-1和位置t的输入的函数,从而导致缺少并行化。虽然最新的相关技术提高了一定程度的并行化,但顺序计算的基本约束仍然存在。

注意力机制已经成为各种任务中引人注目的序列建模和转导模型的组成部分,作者提出的Transformer模型架构能避免复发,完全依赖于注意力机制,以绘制输入和输出之间的全局依赖关系。Transformer支持更高的并行化,在8个P100 GPU上训练12小时后,翻译质量就能达到LSTM和GRU的最新水平。

模型架构

Transformer也是由编码器和解码器的结构组成。编码器将符号表示的输入序列(x1,.,xn)转换为连续表示序列z =(z1,…,Zn)。给定z,解码器然后生成输出序列(y1,…,ym)中的每一个。在每一步,该模型是自回归的,在生成下一个符号时,消耗先前生成的符号作为附加输入。

Transformer遵循这种整体架构,编码器和解码器均使用堆叠的自注意和逐点全连接层,分别如下图的左半部分和右半部分所示:
在这里插入图片描述

编码器和解码器堆栈

编码器:编码器由N = 6个相同层的堆栈组成。每层有两个子层。第一个是多头自注意机制,第二个是一个简单的全连接前馈网络。两个子层中都使用残差连接,然后进行层归一化。即,每个子层的输出是LayerNorm(x + Sublayer(x)),其中Sublayer(x)是子层本身实现的函数。为了促进这些残差连接,模型中的所有子层以及嵌入层都产生维度dmodel = 512的输出。
解码器:解码器也是由一个堆栈的N = 6相同的层。除了每个编码器层中的两个子层之外,解码器还插入第三子层,该第三子层对编码器堆栈的输出执行多头注意。与编码器类似,作者在每个子层周围使用残差连接,然后进行层归一化。作者还修改了解码器堆栈中的自注意子层,以防止模型关注后续位置进行作弊。

Attention

注意力函数可以被描述为将查询和一组键值对映射到输出,其中查询、键、值和输出都是向量,输出计算为值的加权和。其中分配给每个值的权重由查询与对应键的compatibility函数计算。
下图为Scaled Dot-Product Attention(标度点积注意力):
在这里插入图片描述

在实际中,同时计算一组查询的注意力函数,这些查询被打包到一个矩阵Q中。键和值被打包到矩阵K和V中。计算的输出矩阵为:
在这里插入图片描述

Multi-Head Attention(多头注意):
使用不同的学习线性投影将查询、键和值分别线性投影h次到dk、dk和dv维。并行执行注意力函数,产生dv维度的输出结果,这些数据被连接起来并再次投影,从而得到最终值,如下图所示:
在这里插入图片描述

多头注意允许模型在不同的位置联合注意来自不同表示子空间的信息。对于一个单一的注意力头,平均化抑制了这一点。
在这里插入图片描述

其中投影是参数矩阵WQi ∈ Rdmodel×dk,WKi ∈ Rdmodel×dk,WVi ∈ Rdmodel×dv和WO ∈ Rdv ×dmodel。

在这项工作中,作者采用h = 8平行注意层(或称为头)。对于其中每一个,作者使用dk = dv = dmodel/h = 64。由于每个头的维数降低,总的计算成本类似于具有全维度的单头注意。

Position-wise Feed-Forward Networks

该层包括两个线性变换,中间有一个ReLU激活:
在这里插入图片描述

Embeddings and Softmax

与其他序列转换模型类似,该处使用学习的嵌入将输入令牌和输出令牌转换为维度dmodel的向量。作者还使用常用的学习线性变换和softmax函数将解码器输出转换为预测的下一个令牌概率。在该模型中,作者在两个嵌入层和pre-softmax线性变换之间共享相同的权重矩阵,并将这些权重乘以嵌入模型。

Positional Encoding

在编码器和解码器堆栈的底部向输入嵌入添加“位置编码”。位置编码与嵌入具有相同的维度dmodel,因此两者可以相加。
在这里插入图片描述

其中pos是位置,i是尺寸。即,位置编码的每个维度对应于正弦曲线。波长形成从2π到10000 · 2π的几何级数。选择正弦版本,因为它可以允许模型外推到比训练期间遇到的更长的序列长度。

实验数据

在标准的WMT 2014英语-德语数据集上进行了训练,该数据集由大约450万个句子对组成。句子使用字节对编码[3]进行编码,它具有大约37000个标记的共享源目标词汇表。对于英语-法语,作者使用了更大的WMT 2014英语-法语数据集,其中包含3600万个句子,并将标记拆分为32000个单词。句子对按近似序列长度分批在一起。每个训练批次包含一组句子对,其中包含大约25000个源标记和25000个目标标记。

使用Adam优化器[20],其中β1 = 0.9,β2 = 0.98,β 2 = 10^−9。根据以下公式在训练过程中改变学习率:
在这里插入图片描述

实验结果

机器翻译:
在WMT 2014英语到德语的翻译任务中,大Transformer模型(表2中的Transformer(大))比之前报道的最佳模型(包括集成)的BLEU高出2.0以上,建立了28.4的新的最先进的BLEU分数。
在WMT 2014英语到法语的翻译任务中,我们的大模型达到了41.0的BLEU分数,超过了之前发布的所有单个模型,而训练成本不到之前最先进模型的1/4。
英语选区分析:
在这里插入图片描述

表中的结果表明,尽管缺乏特定于任务的调整,Transformer模型表现得令人惊讶地好,产生的结果比所有先前模型都要好,即使只在WSJ训练集的40K句子上训练,Transformer也优于BerkeleyParser。

深度学习

Transformer

Transformer模型是在《Attention is All You Need》中提出的,最初是为了提高机器翻译的效率,它的 Self-Attention 机制和 Position Encoding 可以替代 RNN。因为 RNN 是顺序执行的,t 时刻没有处理完成就不能处理 t+1 时刻,因此很难并行。

Encoder

Encoder组件是由N = 6个同样的Encoder堆叠而成,每一个encoder由一个Multihead attention层和feed forward层(2层前馈网络)组成,同时这两个层都包含残差连接(Residual (short-circuit)connection)和LayerNorm,如下图:
在这里插入图片描述

每一个encoder层如下:
在这里插入图片描述

作为第一个encoder的输出,还是记为X,作为第二个encoder的输入。
文中设置了6个encoder堆叠,重复上述过程6次,记最后即最上层的encoder为X,作为encoder的输入。

Decoder

Decoder组件也是由6个一样的decoder组成,decoder也有Mutihead attention层和feed forward层,但是在两个子层之间增加了attention层,该层有助于解码器能够关注到输入句子的相关部分,与seq2seq model的Attention作用相似。
在这里插入图片描述

在inference阶段,在每个时刻,decoder有两个输入:
在这里插入图片描述

3.位置编码

接下来介绍decoder的详细流程。在模型训练过程中,输出结果即要翻译的结果,仍然记为 在这里插入图片描述,虽然记号和encoder一样,但参数并不共享,不是同一个X。
在这里插入图片描述

在这里插入图片描述在decoder中用Mask矩阵抹去未来信息。矩阵在这里插入图片描述的每个元素aij代表了第i个词与第j个词的内积相似度。用下图所示的下三角矩阵作Mask,黄色部分的值是1,紫色部分的值为0,第0时刻(第0行)只有此时词自己跟自己的相似度,1时刻有和0时刻和1时刻的相似度。
在这里插入图片描述
在这里插入图片描述

不断重复上述过程,直到输出特殊字符停止。
在这里插入图片描述

Transformer的损失函数为交叉熵损失,采用梯度下降法求解参数。

总结

Transformer的优势在于它能够并行计算,从而大大提高了训练和推理的效率。由于自注意力机制的引入,模型能够同时计算每个位置的表示,而不需要像RNN那样逐步处理序列。这使得Transformer能够处理更长的序列,从而在机器翻译等任务中取得了更好的效果。
但Transformer有着较高计算成本和优化难度,模型的复杂性导致在训练和推理过程中需要大量的计算资源,尤其是在处理大规模数据集时,需要大规模并行计算能力。此外,还需要仔细调整学习率、批量大小等超参数,以获得较好的性能。

2024/09/07 17:50:58.429199 2024/09/07 17:50:58.194292 2023/11/02 11:00:42.880908 2439548876 26700 dcm uds dilog_imp.cpp DoLog 37 Info [[MCU client] sent message to the MCU is successfully] 2024/09/07 17:50:58.479229 2024/09/07 17:50:58.244324 2023/11/02 11:00:42.930937 2439598909 26701 dcm doip DilogImp.cpp DoLog 39 Info [TestDoipClient receive data: 02 fd 80 01 00 00 00 0a 02 00 01 01 50 01 00 32 01 90 ] 2024/09/07 17:50:58.479315 2024/09/07 17:50:58.244408 2023/11/02 11:00:42.931024 2439598993 26702 dcm uds dilog_imp.cpp DoLog 37 Info [[MCU client] receive data from the mcu succeed!!!] 2024/09/07 17:50:58.479322 2024/09/07 17:50:58.244414 2023/11/02 11:00:42.931031 2439598999 26703 dcm uds dilog_imp.cpp DoLog 37 Info [response data for mcu: 500100320190] 2024/09/07 17:50:58.479330 2024/09/07 17:50:58.244422 2023/11/02 11:00:42.931039 2439599007 26704 dcm uds dilog_imp.cpp DoLog 37 Info [session mode switching, programming session --> default session] 2024/09/07 17:50:58.479366 2024/09/07 17:50:58.244458 2023/11/02 11:00:42.931075 2439599043 26705 dcm uds dilog_imp.cpp DoLog 37 Info [send to dm negative error. serviceId:36 errorcode:2 did/rid:ffff subId:ff] 2024/09/07 17:50:58.479370 2024/09/07 17:50:58.244463 2023/11/02 11:00:42.931080 2439599047 26706 dcm uds dilog_imp.cpp DoLog 37 Info [the timeout of the diagmgr proxy send message is: 36000ms] 2024/09/07 17:50:58.479375 2024/09/07 17:50:58.244467 2023/11/02 11:00:42.931084 2439599051 26707 dcm uds dilog_imp.cpp DoLog 37 Info [the call of FireSoCUDSReqEvent is starting] 2024/09/07 17:50:58.479481 2024/09/07 17:50:58.244574 2023/11/02 11:00:42.931190 2439599158 26708 dcm uds dilog_imp.cpp DoLog 37 Info [the call of FireSoCUDSReqEvent success] 2024/09/07 17:50:58.480358 2024/09/07 17:50:58.245451 2023/11/02 11:00:42.932067 2439600035 26709 dcm uds dilog_imp.cpp DoLog 37 Info [received response message from diagmgr, data: 6E030E] 2024/09/07 17:50:58.480385 2024/09/07 17:50:58.245478 2023/11/02 11:00:42.932094 2439600063 26710 dcm uds dilog_imp.cpp DoLog 37 Info [receive data from the diagmgr succeed!!!] 2024/09/07 17:55:54.166724 2024/09/07 17:55:53.931818 2023/11/02 11:05:38.618432 2735286403 26711 dcm doip DilogImp.cpp DoLog 49 Error [doip client general incativity timeout 300848ms]
10-12
<think>我们正在分析DCM(诊断通信管理器)与UDS(统一诊断服务)以及DoIP(基于IP的诊断通信)相关的日志问题。 用户提到了一些具体的日志条目,包括: - 发送负响应错误,serviceId:36 (TransferData), errorcode:2 (conditionsNotCorrect), did/rid:ffff, subId:ff - 消息收发情况(可能指消息发送和接收的问题) - 会话模式切换(可能涉及默认会话、扩展会话等的切换问题) - DoIP客户端通用不活动超时(300848ms,约5分钟) 根据AUTOSAR架构[^1],DCM模块负责处理诊断请求,包括会话管理、安全访问、数据传输等。DoIP则是在TCP/IP网络上传输诊断数据的协议。 我们将逐一分析每个问题: 1. **发送负响应错误(serviceId:36, errorcode:2)** 该错误表示在执行TransferData(0x36)服务时,条件不满足(errorcode=2)。可能的原因包括: - 未正确进入扩展会话(Extended Session)或其他支持数据传输的会话模式。 - 安全访问未解锁,而TransferData服务需要特定的安全级别。 - 数据传输序列错误:TransferData必须在RequestDownload(0x34)之后调用,且必须按照块序列号顺序(从1开始,每次递增1)。 - 参数无效:DID/RID为0xFFFF通常表示无效标识符,而subId=0xFF也超出了范围(子功能ID通常为0x00-0x7F)。 解决方案: - 检查会话状态:确保在发送TransferData请求之前,ECU已经切换到支持该服务的会话模式(如扩展会话)。可以通过发送$10 03$(进入扩展会话)来切换。 - 检查安全访问:如果TransferData服务需要安全访问,则必须先执行安全解锁(如服务$27$)。 - 检查数据传输序列:确保TransferData请求紧跟在一个成功的RequestDownload请求之后,并且块序列号正确(第一块为1,后续递增)。 - 验证参数:检查DID/RID和subId是否在ECU的支持列表中。避免使用0xFFFF和0xFF等保留值。 2. **消息收发情况** 可能涉及诊断消息的发送或接收失败。在DoIP协议中,这可能是由于网络问题或协议错误导致。 - 原因: - 网络连接断开(如TCP连接断开)。 - DoIP协议版本不匹配。 - 消息格式错误(如长度域错误)。 - 接收方未及时响应(处理超时)。 - 解决方案: - 检查网络连接(例如,使用ping测试)。 - 验证DoIP协议版本(诊断仪和ECU应支持相同的DoIP版本,如ISO 13400)。 - 检查消息格式是否符合DoIP标准(包括头部的协议版本、反码、载荷类型、长度等)。 - 配置适当的超时时间,并确保ECU处理诊断请求的时间在超时时间内。 3. **会话模式切换** 在UDS中,会话模式切换(如从默认会话切换到扩展会话)是诊断操作的基础。如果切换失败,可能导致后续服务无法执行。 - 原因: - 会话切换请求($10 03$)未被正确处理(如ECU未启用该会话)。 - 会话保护定时器(S3 timer)超时导致会话自动退回默认会话。 - 安全访问未完成,某些会话需要先解锁。 - 解决方案: - 确保ECU配置支持所需的会话模式(如扩展会话)。 - 在会话成功切换后,定期发送TesterPresent($3E$)以保持会话活跃(防止S3超时)。 - 对于需要安全访问的会话,先执行安全解锁。 4. **DoIP客户端通用不活动超时(300848ms)** 这个超时表示在约5分钟内,DoIP客户端(诊断仪)没有发送任何消息,因此ECU主动断开了连接。 - 原因: - DoIP协议规定,如果一段时间内无通信,可以关闭TCP连接以节省资源。这个超时时间(300848ms)是ECU配置的参数。 - 解决方案: - 在长间隔期间发送DoIP协议层的心跳消息(如DoIP的车辆识别请求)或诊断层的TesterPresent($3E$)服务来保持连接。 - 调整ECU的DoIP配置参数(通用不活动超时),但需注意这会影响资源占用。 系统日志分析建议: - 在DCM模块中,增加详细的日志输出,包括会话状态、安全状态、服务调用序列等。 - 对于DoIP通信,记录完整的消息收发(包括头部和载荷)以便分析。 代码层面建议(针对DCM): - 在TransferData服务入口处,添加条件检查: ```c // 伪代码示例 void Dcm_Service_TransferData(Dcm_OpStatusType OpStatus, Dcm_MsgType* RequestMessage) { // 检查会话状态 if (Dcm_SesCtrl_getCurrentSession() != DCM_EXTENDED_SESSION) { Dcm_SendNegResponse(DCM_E_CONDITIONS_NOT_CORRECT); return; } // 检查安全状态 if (Dcm_GetSecurityLevel() < REQUIRED_LEVEL_FOR_TRANSFER_DATA) { Dcm_SendNegResponse(DCM_E_SECURITY_ACCESS_DENIED); return; } // 检查是否在RequestDownload之后(即数据传输已启动) if (!Dcm_IsDataTransferActive()) { Dcm_SendNegResponse(DCM_E_CONDITIONS_NOT_CORRECT); return; } // 检查参数:块序列号、数据长度等 // 继续处理... } ``` 针对DoIP的超时问题,可以在客户端(诊断仪)实现心跳机制: ```c // 定期发送TesterPresent(0x3E)服务,子功能0x00(无响应) void SendTesterPresent() { uint8 msg[2] = {0x3E, 0x00}; DoIP_SendDiagnosticMessage(msg, 2); } ``` 或者,在DoIP协议层,可以配置更长的超时时间(如果允许): ```ini ; DoIP配置 [General] InactivityTimeout = 600000 ; 10分钟 ``` 总结:此问题涉及多个方面,需要检查会话管理、安全访问、服务调用序列、参数有效性以及网络连接。同时,注意保持连接活跃以避免超时断开。 相关问题: 1. 如何配置DCM模块以支持不同的UDS服务? 2. DoIP协议中超时参数有哪些?如何设置? 3. 在UDS协议中,如何处理安全访问(Security Access)服务? 4. 如何确保数据传输(TransferData)服务的块序列正确性? </think>### DCM UDS/DoIP日志问题分析及解决方案 #### **1. 发送负响应错误 `serviceId:36 errorcode:2`** **问题描述** 日志 `send to dm negative error. serviceId:36 errorcode:2 did/rid:ffff subId:ff` 表明: - **ServiceId:36**:UDS的`TransferData`服务(数据传输)[^1]。 - **Errorcode:2**:`conditionsNotCorrect`(条件不满足)[^1]。 - **DID/RID:0xFFFF, SubId:0xFF**:无效参数(保留值)。 **根本原因** $$\begin{cases} \text{会话状态错误:未进入扩展会话(需}10\ 03\text{)}\\ \text{安全访问未解锁:服务需}27\ \text{安全认证}\\ \text{序列错误:未先调用}34\ \text{(RequestDownload)}\\ \text{参数非法:DID/RID=0xFFFF(保留值)} \end{cases}$$ **解决方案** ```c // 步骤1:校验会话状态(伪代码) if (current_session != EXTENDED_SESSION) { SendNegativeResponse(SERVICE_NOT_SUPPORTED); // NRC 0x7F Log("Requires extended session"); } // 步骤2:校验安全访问 if (GetSecurityLevel() < LEVEL_3) { // 示例安全级别 SendNegativeResponse(SECURITY_ACCESS_DENIED); // NRC 0x33 } // 步骤3:校验服务序列 if (!IsDownloadActive()) { // 检查RequestDownload是否已调用 SendNegativeResponse(CONDITIONS_NOT_CORRECT); // NRC 0x22 } // 步骤4:校验DID/RID参数 if (did_rid == 0xFFFF || !IsValidDID(did_rid)) { LogError("Invalid DID: 0x%04X", did_rid); SendNegativeResponse(REQUEST_OUT_OF_RANGE); // NRC 0x31 } ``` > 关键点:需通过`TesterPresent`($3E$服务)维持会话[^1]。 --- #### **2. 消息收发故障** **问题现象** - 诊断消息丢失或响应超时。 - DoIP层报文校验失败。 **原因分析** $$\text{丢包率} \propto \frac{\text{网络抖动} + \text{TCP重传超时}}{\text{带宽}}$$ - **网络问题**:IP链路不稳定(如交换机故障)。 - **协议错误**: - DoIP报文头格式错误(如长度域≠实际载荷长度)。 - ECU未响应`RoutingActivationRequest`(激活请求)。 - **配置错误**: - DoIP实体地址冲突(多个ECU使用相同逻辑地址)。 **解决方案** ```mermaid sequenceDiagram 诊断仪->>ECU: RoutingActivationRequest (0x0005) alt 激活成功 ECU-->>诊断仪: RoutingActivationResponse (ACK) 诊断仪->>ECU: 诊断消息 (如10 03) ECU-->>诊断仪: 正响应 (50 03) else 激活失败 ECU-->>诊断仪: NACK (错误代码0x00-0x0F) end ``` - **网络修复**: - 使用`ping`测试ECU IP可达性。 - 检查交换机端口错误计数(如CRC错误)。 - **协议调试**: - 捕获DoIP报文,验证头部格式: $$Header = [\underbrace{02}_{\text{协议版本}}, \underbrace{\text{FD}}_{\text{反码}}, \underbrace{\text{0001}}_{\text{载荷类型}}, \underbrace{\text{0000000A}}_{\text{数据长度}}]$$ --- #### **3. 会话模式切换失败** **典型日志** `Session switch failed from default to extended` **故障原因** - **S3定时器超时**:未在限定时间(通常5s)内收到$3E$(TesterPresent)维持报文。 - **依赖服务未执行**:扩展会话需先通过$27$(SecurityAccess)解锁。 - **资源冲突**:其他进程占用DCM资源(如刷新操作锁死会话)[^3]。 **解决流程** ```c void HandleSessionSwitch(uint8 target_session) { if (target_session == EXTENDED_SESSION) { // 检查安全解锁状态 if (g_security_level < UNLOCK_LEVEL) { TriggerSecurityAccess(); // 启动27服务流程 } // 启动S3定时器 StartTimer(S3_TIMER, 5000); // 5秒超时 } // 切换后每2秒发送TesterPresent SchedulePeriodic(2000, SendTesterPresent); } ``` > 预防措施:配置S3超时时间为10秒(需符合ISO 14229标准)。 --- #### **4. DoIP客户端通用不活动超时(300848ms)** **问题本质** - 300848ms ≈ 5分钟,表示TCP连接因长时间无数据被ECU主动断开。 - 违反DoIP标准(ISO 13400):**通用不活动超时应≤4分钟**。 **解决步骤** 1. **调整ECU配置**(DoIP模块参数): ```ini [DoIP_Parameters] GeneralInactivityTimeout = 240000 ; 改为4分钟(240秒) ``` 2. **诊断仪保活机制**: - 每60秒发送`DoIP_AliveCheckRequest`(载荷类型0x0008)。 - 或发送UDS层$3E$ 00(TesterPresent无响应子功能)。 3. **防火墙策略**: - 允许DoIP端口(13400/TCP)的长连接(设置TCP Keepalive)。 --- ### 相关问题拓展 1. UDS的$31$(RoutineControl)服务调用失败时,如何区分是条件不满足(NRC 0x22)还是子功能不支持(NRC 0x12)? 2. DoIP协议中,如何诊断`RoutingActivationResponse`返回NACK代码0x05(未知目标地址)? 3. 在多ECU场景下,如何避免AUTOSAR DCM模块的会话状态机被并发访问破坏[^3]? 4. DoIP的车辆发现(Vehicle Discovery)流程中,为何需要同步发送UDP广播和TCP单播? > 总结:核心问题围绕**协议合规性**(ISO 14229/13400)和**状态机完整性**。需结合DCM日志、网络抓包和AUTOSAR配置联合分析[^1][^2]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值