【论文阅读】基于隐蔽带宽的汽车控制网络鲁棒认证（二）

第三章 识别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节中介绍的所有通道的高级抽象，然后进行具体实例化。隐藏带宽通道以后称为寄生通道，它们建立在宿主通道之上。

在建议的每种寄生通道中，功能依赖于提供消息流的某些宿主通信通道，该消息流将由该寄生通道利用。自然，宿主通道提供的带宽会影响寄生通道的带宽。更具体地说，该宿主通道的数据包速率等于每秒用于构建在其上的隐藏带宽通道的消息量。因此，当用b_par(比特/消息)表示隐藏带宽通道每条宿主消息传输的比特量时，与宿主通道的消息速率m_host(消息/秒)相乘，得到该寄生通道的带宽(bw_par(比特/秒)):

明确 b_par 概念。3.3节中介绍的一些寄生通道，是根据每个宿主消息传输的比特数N来明确定义的。因此，在为这样一个特定的寄生通道实例化时，式(3.1)中的b_par可以简单地用N代替。信道ID1、D1、D3和E1在带宽公式构建上属于这一类。

从行为的变化中得出 b_par。引入的其他寄生信道不传输实际的比特，但根据要通过隐藏带宽传输的信息，使宿主信道表现不同。当表达寄生通道在每个消息传输上可以导致宿主通道表现出的不同行为状态的数量 s 时，计算其二进制对数得到可以编码在一个行为状态中的隐藏比特数，从而可以在操纵一个宿主通道消息的传输时传输。计算结果如式(3.2)所示。这种行为状态的具体定义取决于所考虑的特定寄生通道，下文将对此进行详细阐述。

在ID2中，在CAN总线上引起的碰撞数量定义了一个不同的行为状态。由于参数c可以在ID2通道的不同实例中变化，因此它是其带宽公式的变量。相反，在E2中只可能有2种不同的状态，即CRC检查通过或失败，这意味着它的带宽公式显示除了m_host之外没有其他依赖关系。

关于T1，定义传输的隐蔽有效载荷的不同行为状态对应于发送方控制下的数据包的不同顺序。假设i描述了由该发送器控制的不同消息id的数量。然后，在任何can包之前最多可以有i个不同的消息id，从而产生尽可能多的不同的行为状态，这些状态可以由寄生通道每个宿主通道消息组成。那么最多i个不同的消息ID可以出现在任何CAN包之前，产生由寄生通道组成的每个主机通道消息的许多不同的行为状态。

T2在识别其不同的行为状态方面表现出一些复杂性。根据定义，消息之间偏离规则时间间隔T的不同量构成不同的行为状态。发送方和接收方在分别创建和识别该通道中的不同行为状态时，都受到其软件实现寄生通道逻辑的时钟粒度的限制。此外，CAN总线的时钟频率也限制了消息计时的粒度。因此，可能偏离主机消息间隔T的总时间2T通过除以可获得的软件时钟粒度和CAN总线速度的最小公倍数(LCM)来调整为一个 a_eff 变量。因此，a_eff 描述了该CAN总线上的软件可区分偏移量的数量，根据式(3.2)，将采用二进制对数来产生式(3.1)中的 b_par 。

由于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通道中使用了沉默位的概念。它们分别在每个隐蔽信息的前面和后面表示它的开始和结束。为了说明这一点，假设在隐蔽消息的开始发送了 s_start 沉默位，在结束处发送了s_end 沉默位。那么，在通信一条长度为 n_m 的隐蔽消息时，需要传输的隐蔽比特数 n_total 可以计算如下，其中用于错误检测的比特数为 n_e :

这个等式说明了如何扩大了用于分隔隐蔽消息的沉默位的数量，如何降低该IAT信道的有用带宽。事实上，当需要更多的沉默比特来分隔IAT消息时，必须专用更多的非隐蔽流量来覆盖IAT消息。然而，沉默位还有另一个用途，作为数据包到达间隔时间的参考水平，如4.1.2节所述。它们的编码对应于等于底层通道消息周期的到达间时间，这允许接收方调整以适应到CAN消息计时的一点运行时影响。从这个角度来看，增加 s_start 和 s_end 为该IAT信道提供了更高的可靠性和对噪声的鲁棒性。

运行的平均水平。由于数据包的间隔到达时间受到CAN总线不可预测的噪声特性的影响，因此IAT通道应该考虑这些变化。正如TACAN[58]所建议的那样，它为此目的提供了一个运行平均机制。引入了一个参数 L ，它指定了一个窗口的大小，在这个窗口上，IAT值的运行平均值是由接收器维持和采样的。这种方法意味着发送方必须相应地调整其内部传输时间，即连续重复 L 次。
与所使用的沉默位的数量类似，增加L降低了该IAT信道的有用带宽，但有助可靠性。当将该通道部署在负载很重的CAN总线上时，L的值较高是合适的，因为预计IAT值会有更多变化。相比之下，由于需要考虑的噪音影响较少，清晰的总线有理由降低L。

图4.1：使用 n_start = n_end = 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值解码为隐蔽位序列 b_receive 是在接收端完成的，通过在接收每 L 个消息时采样其 IAT 值的运行平均值，L 是其运行平均窗口的大小(参见第4.1.1节)。通过计算用于最接近它的编码的 ITT 值，并查找其相应的编码位，该样本 IAT 值 t_sample 被转换为(沉默)位(s)接收。这就是 CAN 总线噪声可能导致解码位与发送方编码的位不对应的地方，因为它可以影响 IAT 值，使其更接近于不同的编码 ITT 值，而不是该发送方实际使用的 ITT 值。
图4.1显示了在消息11001的两个连续传输中测量的ITT-和IAT值的跟踪，使用两个开始和结束沉默位，以及两个错误检测位(参见第4.1.3节)。使用的IAT编码对应于式(4.2)，T = 200ms， δ = 10ms。IAT值显示了噪声(50%总线负载)和清晰CAN总线配置。该图使用_来表示沉默位。请注意 ITT 和相应的 IAT 值之间的差异，这说明即使在 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]。除了其他选项之外，这个 USB-to-CAN 接口可以通过库¹或通过图形用户界面²从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信道噪声的主要来源。