MIL-STD-1553B总线协议（中文版）.pdf-资料库

aa373368190-1115824-4744300845375211597.pdf-第1页.png

第1页 / 共8页

aa373368190-1115824-4744300845375211597.pdf-第2页.png

第2页 / 共8页

aa373368190-1115824-4744300845375211597.pdf-第3页.png

第3页 / 共8页

aa373368190-1115824-4744300845375211597.pdf-第4页.png

第4页 / 共8页

aa373368190-1115824-4744300845375211597.pdf-第5页.png

第5页 / 共8页

aa373368190-1115824-4744300845375211597.pdf-第6页.png

第6页 / 共8页

aa373368190-1115824-4744300845375211597.pdf-第7页.png

第7页 / 共8页

aa373368190-1115824-4744300845375211597.pdf-第8页.png

第8页 / 共8页

MIL-STD-1553 标准 1553 基准的历史和操作规则 MIL-STD-1553 最初被作为一种连接不同子系统的通信总线来开发，实现系统间共享或交换信息。作为总线标准主要用在以下场合: 1. 信息需要在总线终端之间通过数字通信通道传输； 2. 所有总线终端的和用于总线终端之间连接的电气接口需要的是标准定义的接口； 3. 信息要求以一种可靠的, 确定的,命令/回应的方式传输。由于当时普遍的系统体系结构对点对点布线方式是有所限制的，所以产生了对通过数字串行模式通信的总线标准的需要。通过用 1553 总线取代多导线点对点配置，能减少系统的布线重量,同时提高了整个系统的可靠性。串行传输率在最初(早在 1970 年代 )的标准定义下，串行总线传输位速率 , 1 Mbps,是基于几种因素限制的 , 包括可靠性,电气接口,和硬盘容量。对现代标准来说传送位速率当然快的多，但无论如何,当时 1553 终端在这种带宽限制的应用中是操作的得心应手的。总线终端的特性和连接通过对总线终端电气特性和终端到总线连接标准的定义,使系统体系结构从电气接口角度上得到一种高层次的提高。如果给出一套终端连接和通信格式的规则和指导方针 ( 1553 总线和 MIL-HDBK-1553 标准大纲)，系统设计者就能设计出一种可靠的接口总线网。反之考虑,终端设计者应该有一套可追随的标准，来确保他们的设计能适应系统级别体系结构的应用。通信和可靠第三,而且是容易误会的一点,就是对于确定的,可靠的,命令/回应通信总线的需要。首先要知道 1553 总线最初是作为一种命令与控制式总线标准被开发的。它未被想象成象今天的大多数高速本地区域网络 (LANs)一样作为 "数据转移"网络。如果你将它的最大只允许传输 64 字节(32、16-bit 字)数据包的协议和信息技术标准与现今的 LAN 标准相比，你就会相信这一点。这种总线标准为了强调信息包能在小的、预定的时间窗口下传输而能确保它的持续和完整性，所以限制了数据包的长度。不象现代局域网,有一个典型的低层数据传输约定， 1553 只专一的提供数据总线通信.所有在总线上的命令和数据都由一个单独的 BC（总线控制器）激活，除了 BC，任何终端无法激活总线通信。BC 的责任是，确保它的信息计划表能为所有对时间依赖性较强的处理过程提供合理的任务分配。除了个别事务类型以外,总线终端 (参考作为 RTs)可为当前进行的总线事务的成功或失败提供状态指示。为了实现完整的总线控制模式, 1553 标准尽量要求 RTs 在指定的时间间隔内回应 BC 发出的命令。如果回应在标准所指定的时间间隔内未被接收到,BC 有权判断当前事务正处在“无回应”状态，并继续进行它的下一个任务过程。这种分配方式意味着可以确保没有总线事务会超过限定时间，否则一个超时的任务会影响其它的总线事务，造成中断或暂停。

标准的调整 MIL-STD-1553 推出多年后，进行了几次标准调整。多数调整是由于对一些不明确领域的涉足或为了和一些有特殊需求的用户之间进行调节所引起的。目前的标准是 revision B, Notice 4. 注意：不同于 Notice 2 。Notice 3 和 Notice 4 没有改变标准的目录，仅仅作了一些标题的改变。 Society of Automotive Engineers 组织(SAE)担任维护和应负任何将来标准调整的责任。大多数现代系统采纳 MIL-STB-1553B Notice 2 规格，有些老的平台也可能涉及到一些 MIL-STD-1553A 和 MIL-STD-1553 终端匹配问题。除了标准之外 ,许多主要平台的承包人也出版了一些关于自身所用平台的实现细节的大纲文档。这些细节包括为系统设计者和终端维护者提供的一些特殊的技术方案，当你在数据总线标准实现过程中遇到解决不了的困难时，它给你提供巧妙的退路。 MIL-STD-1553 涉足领域 MIL-STD-1553 已经发展成为优越的,国际公认的数据总线标准，被利用在许多军事平台上并逐渐进入非军事上一些空白的应用领域。MIL-STD-1553 已经被世界性的采用在空军,海军,陆军装配上,即使是没有应用的国家，她也会代理这种产品。平台不仅局限于航行器上，稍微举几个例子，它还被利用在坦克、轮船、导弹、人造卫星、国际空间站上。另外，地面基础设施上也有 1553 的角色，比如测试设备,模拟器,和训练器。 1553 中字和信息定义 1553 字结构所有的 1553 字都是 20bit 长。每个字包含 3 位同步位, 16 位数据/命令/状态位,和 1 位校验位。同步和奇偶校验位被 1553 硬件用在确定 1553 信息格式和数据错误的时候。 Figure1 :1553 的命令、数据，和状态示图 1553 信息组成一条 1553 信息由一个或多个字组成，并至少包含一个命令字。除了个别方式的命令外，所有信息, 包含至少一个数据字并且可能是三十二位数据字。信息被按照整数信息间断分隔开，间断的范围是从前

一个信息最后一位的中位归零交叉点到下一个命令同步字的中位归零交叉点。换句话说，整数信息间隔包含 0.5s 的奇偶校验信号，接着字间几微秒的总线死区(零电位),和 1.5s 同步信号。下列段落描述标准规划的几种不同信息格式。典型系统命令典型的系统包含控制 BC 到 RT, RT 到 BC, 和 RT 到 RT 信息的 BC 命令，用于满足读、写和在计算机间处理数据的系统需要。下列段落提供一些 BC 命令的简要描述。 BC 到 RT 一个 BC 到 RT 的传输允许 BC 给 RT 传输数据或命令。Figure 2 是 BC 到 RT 信息组件的示图。许多系统应用 BC 到 RT 信息控制 BC 给 RT 子系统传送初始化指令或程序数据。 Figure 2: BC 到 RT 信息示图 RT 到 BC RT 到 BC 的传输允许 RT 传输子系统数据给 BC 以便处理。Figure 3 提供 RT 到 BC 信息组件的示图。 BC 可以利用一条 RT 到 BC 信息从 RT 获得传感或程序数据。 Figure 3: RT 到 BC 信息示图 RT 到 RT BC 可以命令 RT 给其他 RT 传送数据。Figure 4 提供 RT 到 RT 信息组件的示图。这种类型的信息提供了一种机制，当 BC 在处理过程中不需要进行数据交换时， RT 可以给另一个 RT 传送数据。 Figure 4: RT 到 RT 信息示图

方式代码是 BC 命令,它提供网络管理功能.Figure 5 提供三种方式代码信息类型组件的示图。举一些方式代码功能的例子：它可以复位终端,同步子系统时间,和指挥 RT 开始系统自测试. 模式代码 Figure 5: 三种方式代码信息类型示图 MIL-STD-1553B 协议说明书提前确定了方式代码,然而它的前一版 , MIL-STD-1553A,没有提供任何方式代码定义。在许多发自在 MIL-STD-1553A 之前的老系统设计中, 使用的是独特系统方式代码和从厂商得到的专用系统设计说明。散播命令当 RTs 从所有其他 RTs 接受数据或向它们回应系统级别方式代码命令的过程发生时，BC 先要给 RTs 传送一个命令，告诉它怎样完成该做的事务。Figure 6 提供四种散播类型组件的示图。举一些散播功能的例子：它包括内部测试(BITs)的执行,完整定位系统时间(GPS)的同步和 IRIG 时间同步。 Figure 6: 四种散播信息类型示图 1553 系统层次设计考虑前几段陈述了 1553 标准历史，含括从协议到信息级的总线操作概貌。以下段落陈述了终端开发的需要，包括系统级开发。

1553 终端开发的考虑首先要知道设计终端需要什么，然后才能设计 1553 总线终端。MIL-STD-1553 定义了三个终端的因素:BC, RT,和 BM。为它们定义了自身协议和电气要求,终端的开发者将根据所开发项目考虑不同的终端因素。一个 BC 的开发则需要所有层次的设计信息。因为 BC 要负责初始化所有总线事务，和协调所有的终总线控制器端,所以 BC 开发必将涉及以下事项： • 更新速率和总线终端的延迟 • 处理与终端提供的数据相关的需要 • 总线事务的计划分配 (不定期的计划表设制, 信息重执等) • 出错报告 • 对总线控制或相关事项的备份 • 数据有效性的考虑("陈旧"数据处理和双缓冲设制方案) • 终端管理技术(终端同步,终端轮询等) 此外,给 RT 开发者提供有关出错报告的要求,方式代码的要求,以及 BC 命令和数据的格式，也是 BC 开发者的一项责任。远程终端 RT 开发者必须了解在系统中终端向 BC 发出或从 BC 接受数据所需要的信息。因为 1553 标准并没有确定数据字的内容,所以 RT 开发者可以任意按照自己满意的需要去定义字格式。对于 RT 开发者最重要的一点是,要能提供详细的有关对于 BC 可行的数据包的信息,能知道从 BC 发送来的信息的数据字内容, 并且知道这些字内容将会产生什么样的效果。还有几点因素也很重要，列述如下： • BC 需要详细的方式代码(1553B)的组成结构信息 • 所有信息都需要有错误处理功能 • RT 有可能被当作一个备用 BC，如果是这样，RT 就需要具有机械化特性另外，将有关 RT 的处理信息更新速率的能力，信息格式，和收到命令后可能发生的任何回应的细节（包括回应延迟）提供给 BC 或系统开发者也是 RT 的责任。总线监视(BM) BMs 并不作总线事务回应，它的功能是存储总线传输信息，稍后对它进行分析。所以 BM 开发者首先要了解自己所涉及的监视操作的级别。他需要知道以下信息： • 需要监视和过滤的总线事务有哪些 • 如何监视传输特性 (电压级别，信号失真模式等) • 监视阶段的持续时间和速率 • 由总线事件引起的触发需要 • 由总线事件引起的对当前正活动的 RT 因素的重配置只有 BM 在 BC 或 RT 中进行自身重配置时， BM 开发者才需要和其他的终端开发者接触。在这种情况下， BM 开发者需要与相关的终端因素共享机械化和数据传输信息。

系统开发中重要的一步是分析总线拓扑。有两种主要的总线拓扑结构：系统级开发 • 单总线 • 多总线相对而言单总线结构较简单。Figure 7 图示了单总线系统结构。在这个结构里，有 1 个 BC，和 1 单总线结构到 31 个多的 RT。如果你投入以下的项目，就应该采取这种拓扑： • 总线终端上的信息需要量，不要求 MIL-STD-1553 提供太多的带宽扩展。 • 不需要对终端功能进行分开隔离。 • 对冗余和易损性问题不很重视的场合。 Figure 7: 单总线系统多总线结构多重总线结构较复杂。Figure 8 描绘了四重总线体系结构。大多数情况下,当单总线不能胜任系统要求时，应用多总线结构，来满足更多的条件。例如,Figure 8 中,分配给 WMUX 的终端与武器相关,分配给 DMUX 的终端与显示相关, EMUX 终端主要控制电子传感器, AMUX 终端主要用于诊断和控制子系统。这种分配是几个功能被区分的一个例子，在单总线系统中不可能作到这一点。然而,终端分配并不是纯粹基于区分功能的目的。象图中所显示的这种子系统的情况,终端分配还可以防止任何单个的总线带宽的溢出。

Figure 8: 多总线航电体系结构多总线结构应用当多总线结构在实现过程中，每个单独的总线都需要有 BC 的功能。这些单独总线的 BC 功能可以取自同一个物理终端，或者分别取自不同的终端。Figure 8 中,使命计算机（主机）提供航电多总线 (AMUX), 显示多总线 (DMUX),和电子作战多总线 (EMUX)；贮备管理计算机提供武器多总线 (WMUX)控制功能。不管是使用单终端，还是多终端的总线控制，主要都是基于能提供冗余功能和解决易损性问题考虑出发的。在许多多总线结构，应用了备用 BC，来保证即使主 BC 发生故障时整个总线平台仍正常运作。Figure 8 中,当万一使命计算机的 AMUX 和 DMUX 功能出现差错时，储备管理计算机将承担备用 BC 角色。EMUX 没有直接和贮备管理计算机物理连接，因为它并不是安全性很紧要的终端,所以不需要冗余功能。同样地, WMUX 也没有备用 BC，因为它也不是安全性很紧要的终端。某些情况下备用 BC 功能被作为系统设计的一部分 ,给备用 BC 传送控制或者从备用 BC 接受控制的具体方式，也要组合进系统设计中。(这是典型的通过离散信号完成的过程)

资料库

MIL-STD-1553B总线协议（中文版）.pdf

相关推荐

行业

热门标签

最新资料