旅游网站建设首选赢旅动力,网站关键词优化怎么做,互联网营销概念,wordpress友情链接页面插件文章目录 第三章 识别CAN中的隐藏带宽信道3.1 隐蔽带宽vs.隐藏带宽3.1.1 隐蔽通道3.1.2 隐藏带宽通道 3.2 通道属性3.3 CAN隐藏带宽信道3.3.1 CAN帧ID字段3.3.2 CAN帧数据字段3.3.3 帧错误检测领域3.3.4 时间通道3.3.5 混合通道 3.4 构建信道带宽公式3.5通道矩阵3.6 结论 第四章… 文章目录 第三章 识别CAN中的隐藏带宽信道3.1 隐蔽带宽vs.隐藏带宽3.1.1 隐蔽通道3.1.2 隐藏带宽通道 3.2 通道属性3.3 CAN隐藏带宽信道3.3.1 CAN帧ID字段3.3.2 CAN帧数据字段3.3.3 帧错误检测领域3.3.4 时间通道3.3.5 混合通道 3.4 构建信道带宽公式3.5通道矩阵3.6 结论 第四章 到达间时间通道的Java实现4.1 信道设计4.1.1 信道稳健性4.1.2 数据编码与解码4.1.3 错误检测:循环冗余码4.1.4 应用:预定义有效载荷通信 4.2 实现技术4.3 信道评估4.3.1 性能参数4.3.2 通道可靠性 4.4 结论 第五章 到达间时间通道的底层实现5.1 通道设计5.1.1 数据编解码5.1.2 由于接收端CAN缓冲区轮询限制了IAT的准确性5.1.3 计算延迟 5.2 实现技术5.3 信道评估5.4 中断驱动实现5.4.1 通道设计5.4.2 实现技术5.4.3 信道评估 5.5 IAT信道噪声源5.5.1 应用逻辑5.5.2 CAN驱动5.5.3 MSP430硬件5.5.4 CAN控制器5.5.5 CAN总线 5.6 结论 第三章 识别CAN中的隐藏带宽信道
为了对CAN通信中隐藏带宽的来源有一个结构化的概述本章对其中的一个子集进行了分类和比较。首先定义了隐蔽信道和隐藏带宽信道的概念。随后在CAN中对其实例化的讨论是通过对与本工作相关的一组通信信道属性的评估来指导的这些属性在介绍隐藏带宽源本身之前进行了详细阐述。最后在矩阵结构中提出了一种综合方法可以直接比较其构成的隐藏带宽信道。
3.1 隐蔽带宽vs.隐藏带宽
为了提供一个框架来解释本文其余部分中使用的术语本节明确说明了传输隐蔽和/或隐藏带宽的含义以及这些类别如何相互关联。请注意这些定义的目的不是无条件的或一般适用的形式化的概念。相反它们是为CAN网络的特定上下文及其说明性示例而构建的。然而它们的核心元素可以很容易地转化为其他类型的交流。
3.1.1 隐蔽通道
这项工作将隐蔽通道定义为数据传输其(1)有效载荷载体利用了非隐蔽通信(这里CAN流量)的底层形式的一些行为属性(2)利用该载体不需要对非隐蔽流量数据对象(这里CAN帧)进行写访问。下面将详细阐述这一定义包括在本工作的背景下被认为最有趣的方面。
定时/存储隐蔽通道。隐蔽传输通常分为两个子类。计时通道使用包计时作为其隐蔽的有效负载载体而存储通道使用所有参与节点都可以访问的内存位置或数据对象。上面的定义没有明确提到这两个类别但允许在隐蔽通信中有类似的子类。 不管其内容如何都可以对CAN数据包的定时进行操作这充分证明了数据包定时是一种隐蔽的有效负载载体。因此所有适用于CAN的定时通道如TACAN[58]提出的IAT (packet Inter-Arrival Time)通道都被认为是隐蔽的。相比之下并非所有在以前的工作中介绍的CAN存储通道都满足这些隐蔽性要求。例如TACAN提议用“隐蔽”有效负载覆盖CAN数据字段的最低有效位(lsb)作为额外带宽的来源这违反了隐蔽定义的第二部分。
在现有工作中的位置。大多数关于隐蔽通信的文献都将其概念描述为通过将其“覆盖”在底层的非隐蔽或公开[59]流量中来隐藏外部方的数据传输。这个概念明确地包含在这里所用的定义的第一部分中。然而除了这些共同点之外类似于TACAN[58]和本工作之间关于LSB操纵是否符合隐蔽通道的分歧以前的研究并没有对隐蔽的更详细定义达成共识因为某些通道被一些作者认为是隐蔽的而另一些人则认为是非隐蔽的。 LSB操纵就是这种中间情况的一个很好的例子。现有研究的一个子集允许隐蔽通道覆盖底层流量帧只要它在应用层不被注意[3,59,48,58]因此将LSB操作归类为隐蔽传输。然而上述定义禁止数据包中的隐蔽通道因此禁止LSB操作无论应用程序逻辑如何这遵循了不同的作者组[16,19]其中包括Lampson[19]在隐蔽通道的原始定义中。
应用程序的依赖。应该注意到这个隐蔽性定义的应用依赖性。实际上用于隐蔽通信的底层传输的行为特性通常来自于控制它的应用程序的性质。因此当构建在不同的应用程序上时一些隐蔽通道会失去其有效载荷载体从而禁用非零隐蔽带宽传输。然而这种情况不会导致违反这种隐藏性定义因为在利用一些隐蔽的有效载荷载体时不需要CAN帧写访问因为根本没有可以利用的。 因此信道是否符合隐蔽条件并不取决于其底层应用程序而取决于其暴露非零隐蔽带宽的能力。这种依赖关系的一个例子可以在TACAN的数据包到达间时间通道[58]中找到该通道在本节前面已经被分类为隐蔽通道并且要求其底层应用程序采用周期性通信。根据定义当建立在非周期非隐蔽通信上时它产生零带宽传输。
安全的影响。在现有文献中大多数“隐蔽”通道都是在这样一种环境中呈现的即它们可以被用于恶意目的更具体地说可以将机密信息泄露到安全策略视线之外。Lampson最初对秘密信道的定义[19]以及美国国防部后来对秘密信道的替代定义[48]都明确要求秘密信道中的发送方与接收方具有不同的特权级别以便通过秘密通信实现安全策略绕过。 根据为TACAN[58]提出的论点这项工作对参与covert和/或hidden的各方的安全特权没有要求(参见第3.1.2节)通信。事实上这里的隐蔽传输是为了防御目的而利用的以努力增加可用的带宽量以保护CAN通信。因此它旨在强制执行安全策略而不是绕过它们这通常要求参与方具有相同特权级别的可能性。
3.1.2 隐藏带宽通道
CAN网络通常只允许其总线作为ecu试图隐蔽通信的公共存储区域。因此在这个特定的上下文中只有少数甚至没有存储隐蔽通道可以被识别因为放置在该总线上的数据完全由can帧组成can帧不允许在3.1.1节定义的隐蔽通信中被操纵。因此本文引入了隐带宽的概念。它用于对本工作背景下感兴趣的通道进行分类但根据第3.1.1节不符合隐蔽条件。
更具体地说隐藏带宽通道将被定义为以下数据传输:(1)利用包含在底层非隐藏带宽形式(这里是CAN流量)中的某些信息载体;(2)在利用该载体时不需要对底层流量数据对象(这里是CAN帧)进行写访问而控制它们的应用程序需要对这些数据对象进行读访问。请注意隐藏带宽通道暴露非零带宽的能力类似于3.1.1节中对隐蔽通道定义的评论取决于其底层应用。在这里依赖关系比隐度定义更明确。
这是一个比隐蔽性弱得多的定义使所有隐蔽带宽都符合隐蔽的条件但反之亦然。事实上隐蔽传输不允许CAN帧操作而隐藏带宽通信可以覆盖其未读部分。然而所有隐藏带宽符合隐蔽条件的反例并不成立正如前面介绍的LSB操作信道的反例所证明的那样LSB操作信道使用CAN帧数据字段中的最低有效位作为其有效载荷载体因此在这里不被认为是隐蔽传输。然而当构建在丢弃许多最低有效位的应用程序上时例如由于精度要求低只要它影响的比特不超过应用程序逻辑中丢弃的比特这种方法就可以被认为是隐藏带宽传输。 表3.1:在CAN中比较隐藏带宽通道时考虑的属性
3.2 通道属性
为了对本章中介绍的传输形式进行结构化比较我们确定了一组核心信道特性。这些构成了第3.5节所示的矩阵的列其中的行在第3.3节中详细说明。应该注意的是这个集合不是详尽的也就是说它没有涵盖讨论通信通道时感兴趣的所有属性。例如通道对其所在CAN总线上噪声的灵敏度会影响在给定上下文中使用的该通道的值但不包括在此选择中。表3.1列出并定义了所考虑的属性。
考虑到3.1节隐蔽/隐藏带宽定义中应用依赖性的备注应用依赖性被显式地包含在这个属性集中。它表示当前的信道是否对可以用于暴露非零隐藏或隐蔽带宽的应用程序构成限制。
实时遵从性可以被认为是应用程序依赖性中包含的一个方面因为实时截止日期是由同一个应用程序施加的但被提议作为一个单独的通道属性。在3.1节的隐蔽/隐藏带宽定义中没有考虑这些实时方面而本章中使用的应用依赖性定义是基于这些定义的。因此它们在这里被认为属于一个单独的通道属性。
在这项工作的上下文中最重要的特征是软件可控性和隐蔽性因为满足这两者的通道对实现目的最感兴趣。信道的软件可控性允许它在can节点和总线之间可移植其隐蔽性非常符合本工作的研究假设并且通常降低了对可用隐蔽带宽数量的应用依赖性。
3.3 CAN隐藏带宽信道
本节详细介绍表3.2矩阵结构中所列的隐藏带宽通道。在该矩阵中使用的通道标识符位于这里对每个通道的描述之前。对于每一种情况都对相应渠道的核心机制进行了详细阐述并在必要时对表3.1中列出的渠道属性进行了一些评论。这一概述是由表2.1所示的CAN框架设计构成的。
3.3.1 CAN帧ID字段
ID1专用ID位。在某些应用程序场景中正常工作所需的不同ID的数量比使用CAN 2.0中所有11或29个ID字段位可能表示的要少。这样的应用程序可以配置为在can帧的(扩展的)ID字段中专用一些位来隐藏数据。由于在每次消息传输时必须通过CAN总线发送一个完整的ID字段因此启用该通道时发送的位数不会比不启用时多或少。这意味着不考虑对实时截止日期的影响。注意由于向后兼容性问题该通道不允许在最初使用11位ID的应用程序中使用扩展ID位进行隐藏数据传输。
ID2:操纵仲裁冲突频率。针对CAN的现有攻击[12,35]描述了如何利用CAN中的仲裁机制对CAN节点发起选择性DoS攻击。该技术可以被重新用作隐蔽通道因为节点可以导致选择性仲裁冲突以便将隐蔽数据传输到其目标节点。因此碰撞的频率可以作为某种隐蔽有效载荷的编码。CAN协议中包含的错误机制可以通过启用重传[45]来保证底层流量不会遭受任何数据包丢失但是这种额外的网络流量可能会导致实时遵从性恶化并且每条消息只允许特定于CAN收发器的重传数量因此只允许发生冲突。此外仲裁冲突的控制通常不可能从CAN驱动软件中实现这限制了本工作中该通道的适用性。
3.3.2 CAN帧数据字段
D1指定LSBs。正如TACAN[58]所描述的那样一些应用程序可以适应在CAN总线上传输的数据精度降低的情况。在这种情况下一定数量的lsb可以用于传输隐藏的有效负载只要不超过底层应用程序允许更改的比特被重新用作隐藏数据。然而这种方法不被归类为真正的隐蔽通道因为它修改了CAN流量这违背了第3.1.1节的隐蔽定义。由于在这个隐藏带宽通道中只对比特进行操作而不改变每个CAN帧传输的比特量也不改变其定时因此这种方法不会影响其底层流量的实时性。
D2控制数据包大小。利用CAN帧数据字段的另一种方法是使用传输的数据包的大小作为隐藏信息的载体通过改变其数据字段的长度和相应的数据长度代码字段的值。这种信道建立的应用必须能够容忍相关的精度变化也就是说它不能在任何时候都要求其CAN帧的数据域中的最大位数类似于D1的应用要求。在这种情况下该通道的带宽取决于可以安全地从每个数据包的数据字段中删除或添加的位数。 由于该信道影响通过CAN总线发送的比特量因此必须考虑其对实时遵从性的影响。然而它允许降低和增加发送的比特量这意味着它不一定会对合规性产生负面影响。
D3:数据字段填充。只要知道应用程序在其通信中使用可预测的(极端情况下是固定的)数据字段长度就可以用隐藏数据填充其数据包中的数据字段使其最大长度为8字节。当然只有当可预测的数据字段长度低于8字节时这个通道才产生非零带宽。此外它增加了生成的非隐藏流量的数量这有可能破坏其实时遵从性。
3.3.3 帧错误检测领域
E1专用CRC字段。由于CAN提供了帧的自动重传当这些帧携带无效的CRC字段时该字段可以在初始传输时被隐藏数据覆盖以便在认为传输错误并重试之前在CAN总线上监视接收器。然而由于CRC字段不能从软件中控制因此该通道对实现目的不感兴趣。此外重传会产生额外的网络流量从而影响底层通信的实时性。 E2错误检测检查通过/失败。以一种比E1提议的侵入性更小的方式可以在数据包的CRC检查通过或失败时嵌入隐藏信息。更具体地说发送方可以故意操纵其CRC字段以便在接收方检查时产生错误。然后监视该信道的接收器可以解码其CRC检查结果的跟踪而不需要相应的CRC字段本身以预期的隐藏有效负载。因此CAN节点已经提供的处理CRC检查的能力被用于该通道中的隐藏带宽通信。然而正如前面讨论E1时提到的CRC字段不能从软件中控制这使得这个通道在这里不那么重要。尽管该信道与应用程序无关但由于消息重传该信道还会产生额外的网络流量从而影响其底层非隐藏通信的实时性。
3.3.4 时间通道
消息的定时与发生非隐蔽通信的协议无关是隐蔽带宽的一个有用来源。如果在软件中提供足够小的时钟粒度并且所考虑的CAN总线上没有过多的负载则可以在消息的传输时间和相应的到达时间中嵌入合理数量的信息。由于该通道类型是软件可控的并且根据第3.1.1节的定义是真正隐蔽的因此它的实例化对于实现目的非常有价值。
T1:数据包重排序。不仅数据包的时序而且它相对于其他数据包的排序都可以是隐蔽数据的编码。更具体地说当应用程序控制具有不同ID字段的数据包传输时它可以将其数据包的顺序调整为可以解码隐藏信息的序列。这种做法显然会影响实时行为因此不能被认为是普遍适用的更不用说它的先决条件是底层应用程序控制多个数据包id。 在表3.2的矩阵概述中列出的该通道的带宽公式假定隐蔽数据在每个数据包的ID字段中进行编码相对于紧接在它前面的消息的ID。这种方法的变体可以考虑更长的消息序列从而产生其他带宽公式。
T2:控制数据包到达间隔时间。即使在不能控制多个CAN消息id的情况下信息也可以在数据包的计时中进行编码更具体地说在它们的到达间隔时间中进行编码。假设一个应用程序使用一些固定的消息间传输时间T进行周期性通信偏离该值T可以编码一些隐蔽的有效负载如TACAN[58]所建议的那样。使接收方监视数据包的间隔到达时间然后使其能够将其解码为相应的隐蔽数据。这种方法显然会危及实时截止日期而且只在使用周期性通信的应用程序中有用。
T3:结合到达时间和重新排序。由于有效载荷的排序与它们之间的时序正交因此T1和T2可以组合成一个混合时序通道。更具体地说信息一方面可以在发送端按照消息的顺序进行编码另一方面也可以按照消息之间的传输时间进行编码。接收器可以从软件监控两者然后将它们解码为相应的隐蔽数据。注意此方法还结合了两个通道的基础应用程序先决条件在本例中是多个消息id的治理和周期性通信。如果应用程序仅控制一个消息ID则该通道将减少为前面讨论的基本到达间时间通道T2。
3.3.5 混合通道
正如第3.3.4节中讨论的T3通道所示本节中描述的几个通道可以组合成一个混合通道。然而在进行这样的组合之前应该满足两个条件:
正交性组合的通道必须是成对正交的即使用一个通道不能干扰其他通道的机制。为了说明这一点使用N ID位来传输隐藏数据(ID1)可以无缝地与can数据域中M个最低有效位(D1)的专用相结合。相反如果数据字段中的一些位通过数据包大小(D2)被删除/添加以进行隐藏通信那么用隐藏数据覆盖这M个最不重要的位就没有任何意义。先决条件兼容性适合混合通道的应用程序必须在适合构成该混合通道的通道的应用程序的公共子集中。因此它们的应用程序先决条件应该是兼容的也就是说它们不应该相互矛盾。这种先决条件的组合已经在第3.3.4节(T3)的混合信道中进行了说明其中T1和T2的组合将适当的应用程序限制为既控制多个消息ID又依赖周期性通信的应用程序。
3.4 构建信道带宽公式
本节详细说明表3.2中列出的带宽公式的构成。
首先进行适用于3.3节中介绍的所有通道的高级抽象然后进行具体实例化。隐藏带宽通道以后称为寄生通道它们建立在宿主通道之上。
在建议的每种寄生通道中功能依赖于提供消息流的某些宿主通信通道该消息流将由该寄生通道利用。自然宿主通道提供的带宽会影响寄生通道的带宽。更具体地说该托管通道的数据包速率等于每秒用于构建在其上的隐藏带宽通道的消息量。因此当用bpar(比特/消息)表示隐藏带宽通道每条托管消息传输的比特量时与托管通道的消息速率mhost(消息/秒)相乘得到该寄生通道的带宽(bwpar(比特/秒)): Explicit bpar。3.3节中介绍的一些寄生通道是根据每个寄主消息传输的比特数N来明确定义的。因此在为这样一个特定的寄生通道实例化时式(3.1)中的bpar可以简单地用N代替。信道ID1、D1、D3和E1在带宽公式构建上属于这一类。
从行为的变化中得出bpar。引入的其他寄生信道不传输实际的比特但根据要通过隐藏带宽传输的信息使宿主信道表现不同。当寄主信道表示不同行为状态的数量时寄主信道可以在每次消息传输中显示为s计算其二进制对数产生可以在一个行为状态中编码的隐藏比特的数量从而可以在操纵一个寄主信道消息的传输时传输。计算结果如式(3.2)所示。这种行为状态的具体定义取决于所考虑的特定寄生虫通道下文将对此进行详细阐述。 在ID2中在CAN总线上引起的碰撞数量定义了一个不同的行为状态。由于参数c可以在ID2通道的不同实例中变化因此它是其带宽公式的变量。相反在E2中只可能有2种不同的状态即CRC检查通过或失败这意味着它的带宽公式显示除了mhost之外没有其他依赖关系。
关于T1定义传输的隐蔽有效载荷的不同行为状态对应于发送方控制下的数据包的不同顺序。假设i描述了由该发送器控制的不同消息id的数量。然后在任何can包之前最多可以有i个不同的消息id从而产生尽可能多的不同的行为状态这些状态可以由寄生通道每个主机通道消息组成。
T2在识别其不同的行为状态方面表现出一些复杂性。根据定义消息之间偏离规则时间间隔T的不同量构成不同的行为状态。发送方和接收方在分别创建和识别该通道中的不同行为状态时都受到其软件实现寄生通道逻辑的时钟粒度的限制。此外CAN总线的时钟频率也限制了消息计时的粒度。这就是为什么可能偏离主机消息间隔T的总时间2T通过除以可用的软件时钟粒度的最小公倍数(LCM)和所涉及的CAN总线速度来调整为一个可变的aef。因此aef描述了该CAN总线上的软件可区分偏移量的数量根据式(3.2)将采用二进制对数来产生式(3.1)中的bpar。
由于T3是T1和T2的正交组合因此其带宽公式的构建简单地为T1和T2的和这在前面已经有详细的阐述。
3.5通道矩阵
本节提供了前三个的综合。第3.2节中介绍的属性对第3.3节中给出的每个通道进行了评估其结果汇总在表3.2的矩阵结构中。通道ID列指3.3节中介绍的标识符。其他列是表3.1中列出的属性这些行对应于这里提出的不同隐藏带宽通道。这个矩阵中列出的带宽公式是按照3.4节的描述构造的。
这个概述的结构允许对CAN中不同的隐藏带宽源进行直接比较并作为构建有关这些通道及其相互关系的有用语句的指南。为了说明这一点矩阵揭示了如何只有时序通道对这项工作相当感兴趣因为它们形成了唯一的类别既可以软件控制又可以根据第3.1.1节的定义被认为是真正隐蔽的。
3.6 结论
本章以CAN中的隐藏带宽源为中心介绍了几个实例并根据一组通信信道属性(如带宽)对它们进行了评估。从实现的角度和研究假设分别考虑说明了这些通道的软件可控性和隐蔽性在本工作的背景下是如何最感兴趣的。然而从引入的通道集来看只有少数通道同时满足两个性质。这并不是说这个讨论没有价值因为所提出的大多数通道都是软件可控的因此在扩展适当的应用程序以利用隐藏带宽方面仍然有用。此外这些考虑促使我们在接下来的工作中关注时序通道。 表3.2:3.3节中描述的CAN通道矩阵基于表3.1中列出的属性其中ID1:专用ID位- ID2:操纵仲裁冲突频率- D1:专用最低有效位- D2:操纵数据包大小- D3:数据字段填充- E1:专用CRC字段- E2:错误检测检查的通过/失败- T1:数据包重新排序- T2:操纵数据包间到达时间- T3: T1和T2的组合
第四章 到达间时间通道的Java实现
为了说明CAN包定时作为隐蔽通信手段的潜力本章提出了一个基于修改包到达间隔时间的传输通道以及它在Java中的实际实现可以在https://github.com/Stienvdh/Java-IAT上公开获得。它提供基本的错误检测并被实例化以将一些固定的有效负载从一个发送方传输到一个接收方。 本文首先讨论其核心概念然后进行绩效评估。
4.1 信道设计
这种到达时间间隔(IAT)通道类似于在TACAN[58]中提出的基于IAT的隐蔽通道依赖于发送方将隐蔽数据编码为数据包的传输时间间隔(ITT)以及接收方监控和解码消息的到达时间间隔。假定这些方采用周期性CAN通信以便可以在偏离其固定报文周期的情况下携带信息。这里这个IAT通道用于传输一些硬编码的隐蔽消息并扩展了用于错误检测的额外数据。然而它的设计允许它作为CAN网络的隐蔽通信通道普遍适用。本节概述其构成机制以及这些机制如何与通道的性能相关。
4.1.1 信道稳健性
沉默位。类似于TACAN的IAT通道[58]在这个IAT通道中使用了沉默位的概念。它们分别在每个隐蔽信息的前面和后面表示它的开始和结束。为了说明这一点假设在隐蔽消息的开始和结束处发送了sstart沉默位。那么在通信一条长度为nm的隐蔽消息时需要传输的隐蔽比特总数可以计算如下其中用于错误检测的比特数为1: 这个等式说明了扩大用于分隔隐蔽消息的沉默位的数量如何降低该IAT信道的有用带宽。事实上当需要更多的沉默比特来分隔IAT消息时必须专用更多的非隐蔽流量来覆盖IAT消息。然而沉默位还有另一个用途作为数据包到达间隔时间的参考级别如4.1.2节所述。它们的编码对应于等于底层通道消息周期的到达间时间这允许接收方调整到CAN消息计时的小运行时影响。从这个角度来看增加启动和发送为该IAT信道提供了更高的可靠性和对噪声的鲁棒性。
运行的平均水平。由于数据包的间隔到达时间受到CAN总线不可预测的噪声特性的影响因此IAT通道应该考虑这些变化。正如TACAN[58]所建议的那样它为此目的提供了一个运行平均机制。引入了一个参数L它指定了一个窗口的大小在这个窗口上IAT值的运行平均值是由接收器维持和采样的。这种方法意味着发送方必须相应地调整其内部传输时间即连续重复L次。 与所使用的沉默位的数量类似增加L降低了该IAT信道的有用带宽但有助于其可靠性。当将该通道部署在负载很重的CAN总线上时L的值较高是合适的因为预计IAT值会有更多变化。相比之下由于需要考虑的噪音影响较少一辆清晰的公交车有理由降低L。 图4.1:使用nstart nend 2沉默位2错误检测位式(4.2)的编码和表4.1的示例参数值在清晰和嘈杂的CAN总线上实现消息11001在Java IAT通道上连续两次传输的传输间和到达时间跟踪
4.1.2 数据编码与解码
编码。在这个IAT信道中发送(沉默)比特的编码是通过让发送方修改L个连续的传输间隔时间t来完成的例如按照式(4.2)其中t是底层CAN流量的消息周期δ是IAT信道特定的偏差参数。 在该信道的实现中提供了如式(4.2)所述的编码以及每个ITT仅传输一个隐蔽位的编码。显然在选择适当的编码时应该小心因为在传输时间内偏离应用程序定义的T值意味着该应用程序可能会错过实时截止日期。此外对于某些应用程序定义的与T的最大偏差应该进行权衡。使用一个小的δ从而在编码中启用许多级别创建了这个IAT信道的更大的理论带宽。相比之下较大的δ因此每个ITT值编码较少的隐蔽位使得该信道对部署在其上的CAN总线引入的IAT值的变化更健壮。更一般地说由于CAN总线的特性到达间隔时间并不完全等于相应的传输间隔时间在设计适当的编码时应该考虑到这一点。
解码。IAT值解码为隐蔽位序列breceive是在接收端完成的通过在接收每条L th消息时采样其IAT值的运行平均值L是其运行平均窗口的大小(参见第4.1.1节)。通过计算用于最接近它的编码的ITT值并查找其相应的编码位该样本IAT值tsample被转换为(沉默)位(s)接收。这就是CAN总线噪声可能导致解码位与发送方编码的位不对应的地方因为它可以影响IAT值使其更接近于不同的编码ITT值而不是该发送方实际使用的ITT值。 图4.1显示了在消息11001的两个连续传输中测量的ITT-和IAT值的跟踪使用两个开始和结束沉默位以及两个错误检测位(参见第4.1.3节)。使用的IAT编码对应于式(4.2)T 200ms δ 10ms。IAT值显示了噪声(50%总线负载)和清晰CAN总线配置。该图使用_来表示沉默位。请注意ITT-和相应的ITT-值之间的差异这说明即使在CAN总线上没有噪声这里考虑的通道鲁棒性措施也不是多余的。
4.1.3 错误检测:循环冗余码
CRC (Cyclic Redundancy Code)是一种比较简单的基于多项式除法[4]的错误检测码。更具体地说与消息一起发送的是它除以某个预定义的N次多项式后的余数。然后接收方可以通过执行相同的除法并检查其余数是否等于传输的CRC来检测位传输错误。当N 1时该CRC算法被简化为在消息中添加一个奇偶校验位。 在这个IAT通道的实现中提供了一个错误检测接口它可以由一个可能不同于CRC的错误检测机制实例化后者提供了模块化。提供了该接口的CRC实现其参数N以及用于除法的多项式可以很容易地修改。然而在确保多项式的次数为N时应该小心。
4.1.4 应用:预定义有效载荷通信
与在此通道实现中进行错误检测的方式类似要在此IAT通道上交换的隐蔽消息通过接口进行交互。 为了便于说明提供了一个简单地重复硬编码负载的协议。然而这种设计的模块化允许使用任何类型的更复杂的通信协议。结合该实现的数据编码/解码设计及其错误检测机制从而构成了具有周期性消息交换的应用程序的通用、隐蔽CAN通信通道原型。
4.2 实现技术
在与CAN交互时此实现依赖于USBtin[11]。除了其他选项之外这个USBto-CAN接口可以通过库1或通过图形用户界面2从Java软件中使用。这个Java实现依赖于前者来发送和接收CAN消息但是IAT通道特定的操作(调整内部传输时间和监视内部到达时间)不需要它的任何功能。这揭示了这里讨论的实现在使用不同的can接口时是如何相当灵活的因为它的核心功能不依赖于它们的细节。
关于CAN硬件部署这种实现的最低要求是一组两个连接的USBtin节点;如果要模拟嘈杂的公共汽车则为三。一个充当发送者的角色另一个成为接收者。可选的第三个实例可用于在can总线上生成随机流量以便将噪声引入该IAT信道。这类噪音的影响将在第4.3节进一步讨论。
4.3 信道评估
本节首先定性地讨论影响该IAT通道带宽和可靠性的参数然后对其Java实现进行定量评估该实现可在https://github.com/Stienvdh/Java-IAT上获得。
4.3.1 性能参数
由于该IAT通道依赖于修改某些应用程序周期性生成的数据包的到达间隔时间因此其性能和其他属性受到该应用程序的强烈影响。例如在CAN网络上每隔10ms发送消息的应用程序可以允许比每隔100ms发送消息的应用程序拥有更高带宽的IAT通道因为IAT值生成的频率更高。其次根据定义这个IAT通道有几个可配置的变量例如公式(4.2)中已经介绍的δ偏移量。最后部署该IAT通道的CAN总线的属性对在其上传输的CAN消息的时间有很大的影响从而对构成该通道的数据包到达时间有很大的影响。总线的噪声越高该信道的可靠性就越低因为在传输过程中IAT值会在占用其CAN总线的噪声帧的影响下偏离。
表4.1列出了评估该IAT通道实现时需要考虑的参数。为了便于说明给出了每个参数的示例值并定性描述了每个参数与该IAT信道的带宽和可靠性之间的关系。请注意这些定性判断仅在所有非相应参数保持不变而相应参数值提高的情况下成立并且除了带宽和可靠性之外该IAT通道还有一些有趣的特性例如与实时截止日期的交互。 表4.1:CAN中影响IAT通道性能的参数 图4.2:在为不同的总线速度和总线负载改变δ并使用表4.1的示例参数值时正确传输的消息与通过Java IAT通道实现传输的消息总量的比率
4.3.2 通道可靠性
到目前为止改变4.3.1节的性能参数的影响只是定性地讨论。图4.2通过显示通过该IAT通道发送的隐蔽消息总数中正确传输的部分来量化这些陈述其中一些性能参数(即总线速度、总线负载和δ偏移)具有不同的值。这些结果是通过使发送USBtin实例在图4.1所示的相同上下文中传输隐蔽消息11001在此IAT通道实现上进行1000次后续传输而获得的。接收USBtin实例监视接收到的通过错误检测(4.1.3节)以及硬编码通信协议(4.1.4节)的消息的数量即接收到的消息被检查以匹配最初传输的消息。第三个usbtin实例用于生成随机流量的50%总线负载。
图4.2证实了关于总线速度、总线负载和δ偏移对该IAT通道可靠性影响的定性陈述。更具体地说更高的总线速度更低的总线负载和更高的δ偏移量都有助于更高的通道可靠性。此外还可以进行一些更具体的观察。例如透明总线的总线速度不会显著影响IAT信道的可靠性。对于10k波特总线速度和100k波特总线速度当δ低于4ms时通道的可靠性降至合理的90%以下。公交车噪声的影响更为明显且与车速有关。更具体地说在有噪声的10k波特总线上在δ 6ms时信道可靠性下降到90%以下在有噪声的100k波特总线上在δ 4ms时信道可靠性下降到90%以下。
4.4 结论
本章介绍了由TACAN[58]提出的隐蔽到达间时间信道的Java实现。它依赖于发送方调整其数据包的间隔传输时间以及接收方监控间隔到达时间从而提供了一种利用额外带宽的周期性CAN通信通道。该实现在错误检测、使用的隐蔽通信协议和数据编码/解码方面被设计为模块化。因此当建立在周期性的非隐蔽消息流上时它可以作为一般适用的隐蔽传输通道。所实现信道的可靠性被定量地评估为受到以下因素的负面影响其中包括部署在CAN总线上的负载降低了该总线的速度并降低了用于编码隐蔽数据的数据包间隔到达时间的变化量。
第五章 到达间时间通道的底层实现
与Java相比为了提高IAT通道的性能本章将其逻辑迁移到底层技术。它首先介绍了这种可选实现的关键机制并激励做出最重要的设计选择。因此构建了一个框架来解释整个过程中呈现的通道性能结果。
5.1 通道设计
使用类似于第4章中介绍的Java实现的方法这个低级IAT通道通过调整非隐蔽的周期性CAN消息之间的初始大小相等的时间间隔来传输一些隐蔽的有效负载。在发送端数据包的传输时间被相应地修改接收端逻辑在将消息解码为相应的隐蔽有效负载之前监视消息的到达时间。本节将更详细地讨论构成该通道的核心概念及其实现。
5.1.1 数据编解码
这里使用的隐蔽有效载荷和数据包间到达时间之间的编码和解码假设在每个长度为T的时间间隔结束时传输CAN消息的底层非隐蔽通信通道。IAT通道本身定义了一个偏移量δ它表示数据包间到达时间中与T的偏差量用于编码隐蔽数据。这种方法与TACAN[58]提出的IAT通道非常相似。
编码。发送端对隐蔽位进行编码将其发送到适当的传输间隔时间这里使用与T的最大偏差为一个δ偏移量编码如式(5.1)所示。注意类似于第4章Java原型中使用的编码也可以使用多个δ偏移的最大偏差。这种方法允许在每个传输间隔时间内编码多个隐蔽位作为对更大实时效果的权衡。 在发送端实际建立传输间时间是通过在tIT T之后设置一个定时器中断来完成的在它的中断服务例程(ISR)中发送该通道的底层应用程序的下一个CAN数据包。 解码。接收端将注册的数据包到达间时间tIAT解码为相应的隐蔽有效载荷breceive这里实现遵循式(5.2)的解码它与式(5.1)的编码相匹配。 在这个实现中IAT值的注册是通过阻塞执行来完成的直到CAN消息到达当它到达时停止计时器然后注册计时器的值最后从零重新启动它。
5.1.2 由于接收端CAN缓冲区轮询限制了IAT的准确性
通过设计本实现中使用的CAN驱动软件在消息接收中使用轮询机制。更具体地说当IAT通道接收端逻辑使用can_recv指示接收消息时它会主动检查CAN控制器接收缓冲区的传入数据包并不断重复该检查或轮询这些缓冲区直到检测到传入流量can_recv返回并且涉及的接收器可以注册相应的数据包到达时间。
因此在两个后续缓冲区轮询之间的时间间隔内到达CAN控制器的所有消息对IAT通道接收器来说似乎是同时到达的。实际上由于这个CAN驱动软件只在缓冲区轮询中处理接收到的帧所以到达时间注册只能在这些相同的时刻完成。在这种情况下任何注册的到达时间都不是精确的而是表示一个轮询间隔内更准确的时间戳。因此这种实现受到一个轮询间隔的IAT测量粒度的限制即无法以周期精确的精度测量到达时间。
在用于该实现的MSP430微控制器[46]上时序实验表明轮询间隔长度为343个周期在20MHz时钟频率下对应于17.5µs。
当然这种接收端IAT粒度会对IAT信道可靠性产生影响。从本质上讲接收方无法准确地监视数据包的到达间隔时间如果该时间不是其接收缓冲区轮询之间时间间隔的倍数。因此发送方必须只产生是该间隔的倍数的分组间传输时间以不破坏理论上的可能性——即当没有任何CAN总线噪声或其他影响IAT信道性能的组件时——完美的IAT信道可靠性。因此需要这样的发送端修改并在这里实现以适应上述接收端IAT测量粒度同时最大限度地提高信道可靠性。
5.1.3 计算延迟
由于此实现中使用的计时器机制在其测量和中断中提供周期精度因此在处理ITT/IAT值时利用这种精度是明智的因为这些值不会受到产生它们时产生的计算延迟的影响。本小节讨论IAT通道实现如何在发送方和接收方的逻辑中解释这种延迟。请注意这里所做的修改是如何依赖于这个特定IAT通道的特定实现的这使得它们背后的推理比它们的技术细节更有价值。
ITT校正(发送方)。在CAN消息的及时传输中计算延迟的主要来源是定时器管理它涉及到发送前一个CAN消息时设置的定时器的终止期望的ITT值的计算以及在ITT间隔之后中断的定时器的初始化在这个间隔之后该序列重复(参见第5.1.1节)。这些计算延迟了计时器的开始当要发送下一条消息时计时器将中断这意味着计时器应该设置一个足够小的间隔而不是打算建立的包间传输时间。
表5.1通过列出IAT通道发送方在发送两个后续CAN消息时所采取的计算步骤来说明这种机制。它表明ITT在CAN总线上的感知方式不仅包括发送方设置的定时器间隔还包括一些定时器管理计算。由于感知到的ITT需要精确到最大的IAT信道可靠性因此应该相应地调整计时器间隔。
在MSP430微控制器上的周期精确定时实验表明这些定时器管理计算引起的20个周期延迟对应于20MHz时钟频率下的1µs。因此该实现从所需的ITT值中减去20个周期然后设置一个计时器该计时器在产生的时间间隔之后中断。因此此实现仅限于ITT值高于20个周期但由于只使用ITT值为343个周期的倍数(参见第5.1.2节)因此没有硬性限制。 表5.1:在两个CAN消息传输之间的到达间时间通道的低级实现中完成的发送端计算并指示在CAN总线上感知到的最终传输间时间。 表5.2:在两个CAN消息到达之间的到达间时间通道的低级实现中完成的接收端计算并指示在CAN总线上感知到的到达间时间。
IAT校正(接收机侧)。与定时器管理在CAN总线上感知到的ITT值中引入计算延迟的方式类似接收端的IAT值也受到影响。更具体地说当接收到先前的CAN消息时计时器开始停止读取和存储其值并重新启动导致每个物理感知的数据包到达时间的一部分不被其相应的计时器结果所解释。
表5.2说明了IAT通道接收器在两个CAN消息到达之间完成的不同计算以及这些计算如何构成计时器结果和计时器管理延迟。由于这两个因素的组合导致了实际的数据包到达间时间因此在IAT值解码之前将计时器管理延迟添加到计时器结果中。
在MSP430硬件上接收端计时器管理延迟测量为126个周期对应于20MHz时钟频率下的6.3µs。
5.2 实现技术
本章中介绍的实现是使用两个支持sancus的msp430微控制器[46]完成的它们都通过spi接口连接到它们自己的MCP2515 CAN控制器[25]进行CAN通信。一个实现接收端功能另一个承担发送方的角色。两者都通过各自的CAN控制器连接到同一CAN总线。当在5.3节中为性能测量引入CAN总线噪声时第4章中介绍的用于Java IAT通道原型的相同USBtin硬件被用于此设置其软件同样用于产生噪声背景流量。 图5.1:在MSP430微控制器上的低水平IAT通道实现中在三种不同的总线配置(明确总线预先记录的后台流量随机50%总线负载)下正确接收不同δ值的传输有效载荷的比例
5.3 信道评估
实验设置。为了评估由本章介绍的低级实现构成的IAT信道的可靠性将发送方配置为调整其周期性通信(周期 15,000个周期)以便在该IAT信道上传输相同的隐蔽有效载荷100次。然后IAT测量接收器解码产生的间隔到达时间并在本实验中扩展以将其结果与预期的隐蔽有效载荷进行比较从而产生此处给出的IAT信道可靠性的测量。此场景重复10,000次收集尽可能多的可靠性测量样本。数据编码和IAT解码分别如式(5.1)和式(5.2)所示。
如第5.1.2节所述在将式(5.1)和式(5.2)中使用的δ值从1到10轮询间隔中改变时执行完整的传输序列。每种配置都是在三种不同的CAN总线条件下测量的;一个除了IAT信道本身没有任何其他交通的清晰总线一个具有50%随机噪声拥塞的总线和一个模拟真实车辆上记录的CAN交通的总线。如5.2节所述通过将usb - tin节点连接到iat发送方和接收方使用的CAN总线可以引入这些不同的噪声源。在所有场景中所使用的CAN总线的波特率为50kHz。
图5.1显示了通过该实验装置获得的测量结果。请注意δ偏移量以343个周期的倍数表示对应于一个轮询间隔(参见第5.1.2节)。
结果在明确的总线条件。如图5.1所示该低级原型在明确的总线条件下在所有δ值为一个轮询间隔的非零倍数时具有100%的可靠性对应于时钟频率为20MHz时17.5µs的最小偏移量。相比之下这种可靠性仅在该通道的Java原型中达到δ至少6ms(参见第4.3节)。 从这些结果中并考虑到所使用的解码方案(参见式(5.2))可以得出结论所使用的can总线的传输时间是确定性的最多可达一半的轮询间隔即在同一can总线上传输相同消息两次所需的时间间隔最多为轮询间隔长度的一半。
50%随机公交拥堵的结果。图5.1显示了在随机背景噪声的CAN总线上与清晰的总线条件相比如何合理地降低通道可靠性。当使用一个轮询间隔的非零倍数δ偏移量时测量的平均可靠性至少为75%。当然扩大δ偏移量的使用有利于IAT信道性能当使用10个轮询间隔的δ偏移量时平均可靠性达到85%。 在噪声总线条件下该IAT通道的Java实现在δ偏移量约为4-5ms时获得了类似的可靠性(参见图4.2)而该实现的偏移量为17µs。这些结果是否符合合理程度的通道可靠性显然取决于应用程序上下文但是相对于Java原型的性能优势是明显的而且与前面讨论的明确总线条件下的相对改进相当。
真实背景流量的结果。从图5.1中可以明显看出预先记录真实背景噪声的CAN总线条件下的结果大致相当于在清晰总线条件下测量的可靠性。平均而言在此总线配置中只有1%的隐蔽有效载荷传输被错误接收。 这些结果激发了该实现在现实场景中的可靠性应用因为在许多应用中99%的隐蔽信息能够成功传输是一个合理程度的消息丢失。然而该信道对其底层通信信道的实时行为的固有后果鼓励进一步降低这种IAT信道可靠性所需的最小δ偏移量这在第5.4节中做了说明。
5.4 中断驱动实现
到目前为止所讨论的低级IAT通道实现的一个主要限制源于其基于轮询的CAN消息接收方法这导致需要一个轮询间隔的软件定义的到达间时间值粒度(参见5.1.2节)。本节探讨了另一种中断驱动的实现该实现旨在实现IAT值的周期精度从而在数据包定时变化较小的情况下实现相等或更高的IAT信道带宽。此实现可在https://github.com/Stienvdh/Sancus-IAT上公开获得。
5.4.1 通道设计
这种中断驱动的替代方案在其核心机制上与基于轮询的替代方案没有区别。实际上隐蔽数据的编码和解码是通过发送方调整其传输间隔时间和接收方监控和解码数据包到达间隔时间的相同过程来完成的方案如式(5.1)和式(5.2)所示。然而这种方法解除了传输间和到达时间需要是一个轮询间隔的倍数的约束通过重新设计在接收端监视到达时间的方式。
中断驱动的IAT值检索
图5.2给出了这种收集IAT值的新方法的图形表示。它显示了在每个CAN消息到达时如何在接收器上触发中断软件定义的中断服务程序在此基础上注册自前一个消息到达以来经过的时间并将其存储在一个循环缓冲区中接收器的软件可以访问该缓冲区以进行解码和/或进一步处理。因此IAT注册在消息到达的确切时刻启动而不是在某个后续轮询间隔结束时启动这显然大大提高了准确性。
这种中断驱动的方法具有使IAT值注册对通道的接收端逻辑完全透明的附加优势。实际上它的实现只需要在接收器的软件中添加一个合适的ISR和一个循环缓冲区以支持其对IAT值的依赖以进行隐蔽通信。相比之下前面讨论的基于轮询的实现涉及在接收者的IAT通道逻辑中模拟类似的注册逻辑。
除了这些机制之外这个实现和之前描述的替代方案在CAN消息的处理和它们的间隔到达时间方面没有区别之后后者已经注册。有了构成这个可选IAT通道的逻辑(例如它需要IAT编码和解码)因此与基于轮询的对应通道没有区别第5.1.3节中描述的用于解释软件级计算延迟的措施可以安全地迁移到这个实现中。然而接收端调整现在是在中断服务程序中应用而不是在主应用程序执行路径中。
消息ID屏蔽和过滤 问题IAT值混淆。由于此实现被设计为在任何数据包到达接收端时注册消息到达间隔时间并且CAN网络基于广播通信因此可能会出现不属于该IAT通道的主机应用程序的消息从而导致到达中断从而导致意外的IAT值注册。因此需要建立一种机制以确保只测量此IAT通道的底层应用程序的消息的到达间计时并将其存储在向接收方应用程序逻辑提供这些IAT值的循环缓冲区中。 图5.2:中断驱动IAT通道的图形表示。接收端的中断允许在软件可访问的缓冲区中注册IAT值发送端的定时器中断允许适当的传输间时间。
解决方案1扩展ISR逻辑。防止这种IAT值混淆的一种简单方法是在注册其计时之前检查CAN数据包的ID是否属于底层应用程序。然而CAN包检测通常涉及相当多的计算延迟这在ISR逻辑中是不太理想的。在这种方法中IAT注册和潜在的消息ID检查是在ISR中完成的这不利于使用第一种解决方案尽管它可以有效地减轻IAT值混淆。
方案2a: ID屏蔽和过滤。用于此实现的MCP2515 CAN控制器(参见5.4.2节)提供了基于其消息ID控制CAN总线上哪些数据包能够进入其接收缓冲区从而导致中断触发的可能性。更具体地说传入消息的ID首先被过滤然后被屏蔽然后才允许它进入这样的缓冲区。这些操作是在硬件级别实现的这意味着它们在IAT注册中产生的延迟很小。此外该机制允许在CAN消息到达时执行相当小的ISR如附录a所述。实际上这个实现中使用的ISR只包含5行C代码。 表5.3:屏蔽和过滤CAN报文id时可能的位配置。破折号表示0位和1位(不关心位)
对消息ID应用过滤器需要在两者之间执行按位异或操作设置结果位序列中过滤器和ID位在其对应位置上不相等的所有位并将所有其他位归零。当应用掩码时对过滤后的结果和掩码执行位与运算当且仅当对应位置的所有原始id位不是未被掩码就是被掩码并等于相应的过滤位时产生一个全零位序列。
表5.3总结了这些操作及其对单个位的处理结果。传入CAN数据包的所有消息ID位必须产生0位以便将手头的消息加载到相应CAN控制器的接收缓冲区中因此在此实现中导致中断。
方案2b:多个接收缓冲区。由于MCP2515提供了两个独立的接收缓冲区这种看似限制的方法可以得到缓解因为它只限制主机应用程序的消息可以从接收方的软件访问。每个都可以独立配置其掩码和过滤器以及当消息进入它们时是否触发中断。因此通过仅在其中一个缓冲区上启用中断、掩码和过滤器此实现仍然可以正常工作同时允许在屏蔽/过滤后接受的其他消息在从第二个缓冲区加载后可供接收方软件使用。 由于此实现仅作为IAT通道的原型因此除了将底层应用程序加载到CAN控制器接收缓冲区之外不需要其他消息。因此两者都屏蔽了完整的消息ID并对其进行过滤以匹配主机应用程序消息的ID。此外当数据包进入任一缓冲区时将触发中断因为这样可以保证它属于构建此IAT通道的应用程序的通信。
5.4.2 实现技术
这个中断驱动通道利用了与之前提出的基于轮询的替代方案相同的硬件(MSP430微控制器[46] MCP2515 can控制器[25]通过spi接口连接)。然而为了启用这种中断驱动的方法对该硬件进行了一些修改以利用MCP2515 CAN控制器中提供的中断功能。更具体地说在每个CAN控制器的专用中断引脚和各自MSP430微控制器上的通用数字I/O引脚之间添加一条线。此外按照该通道的设计规定进行以下配置以实际启用CAN消息到达时的中断处理: 启用CAN控制器中断在CAN控制器上设置专用于两个接收缓冲区的中断使能(IE)位使控制器的中断引脚在CAN消息进入其中一个缓冲区时被驱动为低电平。所有其他CAN控制器中断源(例如传输错误)被禁用因为只有该事件对该实现感兴趣。 此外所使用的CAN控制器仅提供一个专用中断引脚这使得识别CAN控制器中断源的功能留给MSP430软件如果多种类型的事件具有驱动中断引脚低的能力。为了使MSP430中断处理程序从这个额外的逻辑中解脱出来只启用了CAN消息到达中断。 启用MSP430 I/O中断通过每个微控制器与其CAN控制器之间的额外附加线当CAN控制器的中断引脚是时微控制器上的数字I/O引脚将被驱动为低电平这意味着每当CAN消息到达时。在微控制器上设置适当的(即专用于连接到CAN控制器的I/O引脚)IE位允许将此类中断传播到其软件并随后由其软件处理。 设置CAN控制器掩码和过滤器由于CAN是基于广播的协议比微控制器实际感兴趣的更多的消息可能到达其CAN控制器导致比必要的更多的中断被触发这反过来导致IAT值混淆。这个问题以及它提出的配置接收缓冲掩码和过滤器的解决方案已经在5.4.1节中介绍过了。
5.4.3 信道评估
实验设置。用于评估这个中断驱动通道的场景与基于轮询的通道类似(参见5.3节)。一些隐蔽的有效载荷在这个IAT信道上连续传输100次重复10000次。该序列使用从150到350 MSP430周期的δ偏移值执行并在四种不同的CAN总线配置中执行。其中三种(无阻塞总线50%随机总线拥塞预先记录的流量)对应于5.3节中讨论的配置并且在此特定评估中添加了75%随机总线拥塞的四分之一。由于这个中断驱动通道在所有其他总线条件下表现出近乎完美的性能因此添加了最后的总线配置因此意味着证明这种方法的局限性。 图5.3显示了在这些配置中测量信道可靠性的结果通过表明它们的平均消息的正确传输比例以及在所进行的实验中该数字的标准偏差。 图5.3:在MSP430硬件上的中断驱动IAT通道实现中在4总线配置(清除总线50%和75%随机总线拥塞预先记录的后台流量)中正确传输不同δ值的隐蔽有效负载的比例
Results on clear bus, 50% bus congestion, pre-recorded traffic。在所有三种总线配置中(第5.4.3节对基于轮询的实现进行了评估)该通道匹配和/或将基于轮询的通道的性能提高到100%的可靠性使用低于一个轮询间隔的δ偏移量。相比之下基于轮询的通道在50%随机总线拥塞设置和一个轮询间隔的δ偏移量中提供75%的可靠性。 一方面这些结果是由中断驱动的IAT值注册(章节5.4.1)实现的它允许IAT值精度低于343个周期。另一方面传入消息的低级屏蔽和过滤(第5.4.1节)通过不将噪声帧加载到CAN控制器接收缓冲区而不是这样做然后丢弃它们部分地减轻了噪声敏感性就像基于轮询的实现中的情况一样。
导致75%的随机总线拥塞。当将总线拥塞提高到75%时当δ从150到350 MSP430周期变化时通道可靠性下降到平均85到90%。该IAT信道的软件级噪声源已被尽可能地消除因此这种性能下降主要源于噪声流量占用总线这使得构成该IAT信道的非隐蔽流量无法及时到达。下一节将讨论导致该通道性能受限的其他因素。 图5.4:CAN消息在到达间时间通道的低级实现中从发送者到接收者所遍历的软件/硬件栈的图形表示。
5.5 IAT信道噪声源
在本工作中提出的IAT信道的三种实现(第4章第5.1节第5.4节)中仔细考虑了噪声源和信道不可靠性并在认为可能和有效的情况下引入了适当的缓解措施。本节对这些噪声源进行了分类并提供了一系列预防、检测和/或纠正错误IAT通道性能的措施。图5.4说明了当在MSP430硬件上实现时构成IAT通道的CAN数据包所遍历的堆栈从而指导本讨论。
5.5.1 应用逻辑
本小节讨论了源自软件级别的信道缺陷即在控制发送端传输间隔时间的计算和操作的逻辑中以及在接收端对到达间隔时间的监控和解码。当然就减低噪音而言这个级别是最有趣的因为它是最方便调整的。
编程语言属性。用于实现应用程序逻辑的编程语言的特性明显影响其时序特性。这是Java实现中不可靠性的主要来源之一因为Java在其计时特性中表现出很大的不确定性。相比之下由于低级实现可以依赖于周期精确的定时和定时器中断因此消除了非确定性并消除了这种噪声源。
计算延迟。构成适当的ITT/IAT值的逻辑的执行本身就影响其准确性。例如当将隐蔽有效负载编码为传输间定时时计算完成时已经传递了部分有效负载。在管理(停止/读取/启动)测量IAT值的定时器时在接收端引入了类似的计算延迟。
由于为该通道实现的逻辑不包括任何随机和/或非确定性操作因此在两端(发送方和接收方)引入的计算延迟可以被认为是确定性的因此可以在应用程序逻辑本身中有效地解释。第5.1.3节详细阐述了基于轮询的IAT通道实现的这种方法这类似于第5.4节基于中断的实现。
在Java实现中没有采取任何措施来减轻计算延迟的影响。虽然它的逻辑只包含确定性操作但是Java固有的计时不确定性(在本小节前面介绍过)使得测量和计算延迟变得非常不可靠。
5.5.2 CAN驱动
CAN驱动软件通过CAN控制器处理应用程序逻辑和实际CAN通信之间的所有交互。它的特性明显影响最终在CAN总线上测量的ITT和IAT值因为所有传入和传出的消息都要经过它。然而在驱动程序软件中灵活性比应用程序逻辑级别要低因为它的目的是跨多个应用程序移植这可能会因改变其时序特性而受到负面影响。在本章中介绍的低级实现中使用了MCP2515 CAN控制器驱动程序2并且第4章的Java实现利用了USBtin库3来实现此目的。
消息传播机制:传输。在这些实现中使用的所有驱动软件在其传输时间上都表现出确定性因为消息仅使用确定性操作传输并且在准确的时间调用适当的驱动程序接口方法。因此内部传输时间不受CAN驱动程序软件的影响因为它在传输每个底层应用程序消息时引入了相同的延迟。
消息传播机制:接收。Java实现中使用的USBtin库基于拦截串行端口中断用于将传入的CAN消息传播到应用程序逻辑这意味着在接收CAN消息时不会引入软件级别的不确定性。因此在该Java原型中注册的间隔到达时间不受USBtin CAN驱动程序逻辑的影响。 然而MCP2515驱动程序在其传入CAN消息计时中确实表现出不确定性。由于第5.1.2节中介绍的基于轮询的方法在传播数据包时引入的延迟是不确定的因为它取决于数据包在一个轮询间隔内的时间这是不可预测的。
如前所述修改CAN驱动软件是一种不可行的方法这就是为什么在应用程序级别减轻了这种噪声源的原因。最初人为地调整ITT和IAT值粒度使其具有与一个轮询间隔相同的粒度(参见第5.1.2节)这克服了这种不确定性。第5.4节的中断驱动实现通过以中断驱动的方式注册到达时间(参见第5.4.1节)来摆脱这种人为构造它只保留了在驱动层引入的确定性延迟。
5.5.3 MSP430硬件
用于两个低级IAT通道实现的MSP430微控制器影响ITT/IAT值因为在发送端它的定时器外设用于在要传输消息时中断而在接收端定时器外设用于测量到达时间。在第5.4节的中断驱动实现变体中所使用的微控制器的中断机制还会影响到达间时间值的注册(参见第5.4.1节)。
计时器精度。如MSP430规格[46]所述周期精确定时可通过MSP430硬件的定时器外设。因此定时中断以及定时测量不会在ITT和IAT值上引入任何噪声因为两者都是在低级实现中使用该外设获得的。
中断处理机制。中断从其源到应用程序逻辑的传播显然会导致消息传输的延迟以及在中断驱动实现中IAT值注册的延迟。然而MSP430硬件确保这种延迟是确定的因此在应用程序逻辑级别负责。
5.5.4 CAN控制器
在两个低级实现中使用的MCP2515 CAN控制器通过在传入和传出方向上传播CAN消息来影响ITT/IAT值。在中断驱动的方法中这些控制器还用于将传入消息上的中断传播到它们的MSP430微控制器。
消息和中断传播。与MSP430硬件类似MCP2515 CAN控制器的所有消息和中断传播引入确定性因此相对无害延迟为[25]。
SPI接口时钟频率。SPI接口连接每个CAN控制器到它的微控制器在这个IAT通道的低级实现中时钟在10MHz。然而后者的时钟频率为20MHz这意味着ITT/IAT值的粒度至少为2 (MSP430)周期。具体地说在相同的两个周期内发送/到达的两个消息在它们的时间方面对微控制器来说是不可区分的。
MCP2515时钟频率。每个CAN控制器本身的时钟在另一个频率为16MHz。因此软件中的ITT/IAT值应该人为地构造为4的倍数以便不受MSP430微控制器其SPI接口和MCP2515控制器之间的时钟频率差异的影响。
5.5.5 CAN总线
显然构成IAT通道的所有消息都是通过CAN总线传输的CAN总线对它们的ITT和IAT值有主要影响。在图5.4中它是唯一一个不构成该IAT通道的actor会影响其功能的堆栈级别例如当该IAT通道需要总线时actor会占用总线。外部控制的方面使得CAN总线噪声对于信道评估非常有趣因为它不受IAT信道实现控制。
时钟频率。与之前介绍的时钟频率差异类似CAN总线本身具有(可配置的)时钟频率例如500kHz这与MSP430硬件不同。在这种情况下需要为该通道建立40 (MSP430)周期的软件级ITT/IAT值粒度以适应本节中提到的所有时钟频率差异(MSP430微控制器MCP2515 CAN控制器SPI接口CAN总线)。
背景流量。在本研究中广泛讨论了由CAN背景通信量引入的IAT信道噪声及其对信道性能的影响(参见第4.3节、5.3节和5.4.3节)。由于这种噪声来自外部因素因此没有可用的IAT信道修改来克服它。但是可以调整应用程序逻辑以部分减轻后台流量的后果例如通过扩展带有错误检测和/或错误纠正位的隐蔽有效负载这包括在Java原型中并在4.1.1节中讨论。
5.6 结论
本章介绍了IAT通道的Java实现的迁移(参见第4章)到一个低级变体部署在MSP430微控制器与MCP2515 CAN控制器交互。在其高级机制中该实现与Java实现非常相似。然而由于这里使用的技术提供了更精确的定时机制因此可以利用这些机制实现更低粒度的ITT/IAT值从而提高IAT信道的可靠性。这种实现的主要软件级限制是它在CAN消息接收中使用的轮询机制也就是说它的连续缓冲区轮询禁止ITT/IAT值的周期精度。尽管存在这样的限制但最终通道在清晰和嘈杂的CAN总线配置上的性能都明显优于其Java对应通道。
为了进一步提高性能结果还讨论了一种中断驱动的方法来隐蔽CAN中的IAT通信。在该实现中每当消息到达接收端时在其中断服务例程中触发中断该消息的时间被注册从而为接收软件提供接近周期精确的时间。此外对消息id进行过滤和屏蔽以禁用引起此类中断和干扰记录计时的噪声包。因此这种增强的信道在登记隐蔽有效负载编码的间隔到达时间方面提供了很高的准确性与以前提出的实现相比它可以在更低的时间变化下实现更多的隐蔽带宽。对其性能的评估证实在明确的总线条件下以及在50%随机总线拥堵或预先记录的背景交通情况下该实现的可靠性为100%。
除了这些低级实现所减轻的噪声源之外还有几个IAT信道噪声源来自CAN消息所遍历的硬件/软件堆栈中的不同级别。讨论了这些噪声源的概况揭示了CAN总线背景流量是IAT信道噪声的主要来源。
