嵌入式Linux具有稳定、可伸缩及开放源代码等特点，可兼容多种处理器和主机，广泛适用于各种产品和应用。但是，交叉编译、设备驱动程序开发/调试，以及更小尺寸等要求对嵌入式Linux开发者来说都是严峻的挑战。为应对这些挑战，针对嵌入式Linux开发的专用工具应运而生，而且发展十分迅猛。

但是，许多这类开发工具都不兼容非X86平台，而且也没有很好地实现归档备案或集成。在其它开发环境下，组件间的高度集成并没有完全兑现。因此，要想完全从这些免费的软件组件开始创建一个完整的跨平台开发环境，开发者应意识到这将需要大量的调研、实施、培训和维护方面的工作。

Linux是少数既可以在嵌入式设备上运行也可作为开发环境的操作系统之一。这一特性可让开发者在转向此开发系统之前于常用硬件(比如 X86桌面系统)之上开发、调试和测试应用程序和库，因此可减少对标准参考平台和指令集仿真器的依赖。这一技术仅适用于应用程序和库，但不适用于设备驱动程序，因为后者的开发依赖于Linux架构。

开放源代码团体及一些软件供应商可提供设备驱动程序开发工具。由于设备驱动程序比标准应用程序距离硬件更近，因此它们的开发比较困难。所幸的是，Linux桌面系统可以利用一些Windows及其它操作系统所没有的工具。有足够经验开发设备驱动程序的开发人员可能已经习惯将Linux作为他们的桌面开发系统了。

Linux的快速发展及其桌面方案的不断涌现提出了一个重要问题：所选择的工具方案怎样在不同的Linux分布式系统上运行？它们依赖于主机平台的软件配置吗？

有些Linux工具提供独立于主机平台的开发环境，包括一系列可支持开发工具的应用软件、库和实用程序。这一方法几乎将开发环境与主机配置完全隔离开来，因此主机可以是任何Linux分布式系统，而且任何更新和修改都不会影响开发环境的功能。

这种方法的主要缺点是对存储空间的要求有所增加——约200MB，因为它自己实际上相当于一个微型Linux分布式系统。

可用的工具

一个嵌入式Linux产品的开发需要几个阶段，包括为目标板配置和构建基本Linux OS；调试应用程序、库、内核及设备驱动程序/内核模块；出货前最终方案的优化、测试和验证。

有数百种开放源代码开发工具可供选择。只要开发者原意花时间和精力去调研、实施和维护一系列各不相同的工具，总能找出一个完整的解决方案，完成几乎任何开发任务。HSPACE=12 ALT="图1：开发者必须精确地考虑到这些工具的松散集合能提供什么样的功能，以及需要付出多大的努力才能形成完整的解决方案。">

在Linux应用程序和库的调试方面，GNU Debugger(GDB)作为一种标准已有几年的历史。它是一种命令行程序，由多个不同的图形用户界面前端予以支持，每个前端都能以多种方式提供调试控制功能。尽管GDB不是一个完美的方案，但它足够应对各种调试任务，而且已经得到开放源代码团体的广泛支持。

Linux内核或设备驱动程序的调试要比应用程序的调试繁琐得多。

在做调研时，以下方面应特别注意：

什么调试方法支持要开发产品的硬件？

需要什么内核补丁程序？

还需要其它什么补丁程序？

调试界面怎么样，如何使用？

该工具需要调试内核模块及处理虚拟地址转换吗？

还需要其它什么工具才能提供完整的方案？

经过进一步的调查，开发者往往发现工具A和工具B并没有提供完全一致的功能，因为它们是在彼此独立的情况下开发的。结果，开发者必须精确地考虑到这些工具的松散集合能提供什么样的功能，还需要付出多大的努力才能形成完整的解决方案。

如果不同处理器类型间的集成、可用性、互操作性和移植性很关键的话，开发者应考虑购买商用开发工具。这主要是因为将开发一个“免费”方案所付出的努力考虑进去，商用开发工具并不算贵。

Linux BSP

Linux系统有两大主要部分：带设备驱动程序的Linux内核；以及根文件系统，包括系统所需的全部支持应用程序、服务和库。

除了驻留在目标板上的OS组件外，还需要创建一个由GNU Compiler Collection构成的交叉编译环境，为库和二进制程序(binutils)提供支持。

虽然几乎每一个组件都可在网上找到，但在硬件或设备驱动程序支持、集成测试信息、交叉编译指南或软件兼容性方面却很难收集到太多信息。尽管开发者可从网上免费下载各种组件以配置嵌入式Linux操作系统，但每个组件在版本、支持、稳定性和测试等方面的状态则需要开发者自己决定。然后，开发者还要完成最后的OS集成和测试，以及为所开发产品提供终身Linux OS维护。

另一方面，嵌入式Linux供应商所提供的商用Linux板支持工具包一般都是经过预先安装和测试的，而且提供支持和维护。其它须考虑的因素包括Linux桌面主机将会添加不同的库和内核功能，以及由于组织内的开发者变动而引起的长期维护问题。

品质保证部门一般会执行一系列严格的验证和性能测试，其中包括存储器泄漏检测/纠正、代码优化和任务跟踪等。那些想利用开放源代码工具开发面向非X86平台的嵌入式Linux产品开发者将会发现这一任务甚至要比选择开放源代码调试方案难得多。Linux Trace Toolkit、Valgrind工具及其它存储器分析程序可完成部分测试和验证任务。但总的来说，它们缺乏关键特性、集成功能及广泛的硬件支持。这些开放源代码分析工具的评估过程与评估调试方案的过程基本相同。

最后的分析就是，一个设计得恰到好处的开发环境应能够提供商用和开放源代码两个世界所具有的最好特性：

* 交钥匙开发能力；

* 易于使用和集成；

* 大型工程组织的协调控制；

* 品质和支持保证；

* 持续性；

* 按照自己的判断力使用开放源代码的能力。

网络拓扑结构对于汽车网络系统安全具有重要的影响，要保证汽车环境下通讯系统的可用性和可靠性，需要面向特定应用进行优化。在这方面，最近出现的 FlexRay物理层技术具有很大潜力。本文将从简单的网络例子入手，由简至繁，最后推出一种可靠精密的解决方案，在此过程中我们将讨论几种可能的不同网络配置以及它们的优缺点。

FlexRay具有创新的功能和安全的特点，能够使汽车系统安全达到一个很高的水平。FlexRay不仅能简化汽车电子和通信系统架构，同时还可帮助汽车电子单元变得更加稳定和可靠。包括丰田、日产、本田、现代以及起亚汽车公司在内的主要亚洲汽车生产商都已经加入FlexRay联盟，进一步加强了该联盟在创建针对汽车线控操作(by-wire)技术通用标准上所做的努力。随着一些新汽车生产商的加入，全球每年生产的汽车中每10辆几乎有7辆是由FlexRay成员生产。

在开始讨论之前，我们先简单介绍一下FlexRay协议。FlexRay是一种灵活的通讯系统，能够满足未来先进汽车高速控制应用的需要。同时FlexRay支持分布式控制系统，并可补充CAN、LIN和面向媒体应用的MOST光学数据总线等主要车内网络标准。FlexRay协议旨在应用于需要高通信带宽和决定性容错数据传输能力的底盘控制、车身和动力总成等场合。

但FlexRay通信系统并非仅仅是一个通信协议，它还包括一种特殊设计的高速收发器，并定义了FlexRay节点不同部件间的硬件和软件接口。FlexRay协议定义了网络汽车系统中的通信过程格式和功能。除了开发中的协议、软件和支持服务外，FlexRay联盟还致力于通过联盟成员中的领先工具厂商和测试机构来保证提供通信系统设计、测试测量以及仿真所需要的工具。

无论什么时候，控制系统都必须收集实际系统中足够多的信息以保持对汽车的控制并增强其性能。汽车内采用的传感器越来越多，特别是感知外部信息的传感器，用来感知路面信息以及前方、邻近以车辆后面的障碍物，此类传感器包括视频、雷达和光电传感器，它们所捕捉的大量数据都实时传输到车内 ECU进行处理。

FlexRay利用两条独立的物理线路进行通信，每条的数据速率为10Mbps。两条通信线路主要用来实现冗余，因此消息传输具有容错能力，当然也可以利用两条线路来传输不同的消息，这样数据吞吐量可以加倍。

FlexRay还可以工作在较低的数据速率。速度低于1Mbps时，允许支持传输总线结构(如CAN)；速度在1Mbps以上时，不同的节点利用主动星型耦合器以点到点方式进行连接。

FlexRay的重要目标应用之一是线控操作(如线控转向、线控刹车等)，即利用容错的电气/电子系统取代机械/液压部分。线控操作包括从转向到刹车和加速等所有汽车控制应用互连技术，它可以补充并将最终代替目前的机械和液压解决方案。车内部件特别是机械和液压部件减少后就不必再支付这部分费用，因此就总体器件和组装成本来说，采用电子系统比采用机械和液压部件更便宜。

业界正致力于在汽车设计中转向全电子系统，它将通过创新的智能驾驶辅助系统为司机和乘员提供更高的安全性以及更舒适的车内环境。

对于汽车购买者来说，另一项可以感受得到的好处是FlexRay将带来更高设计自由，特别是在汽车内饰方面。由于没有占用很大空间的驾驶杆，未来的汽车将具有全新的面貌和乘坐感觉。除了线控操作以外，FlexRay在汽车动力总成和安全电子系统方面也有很大的应用空间，这些应用都需要高速数据传输，如作为中央电子骨干总线连接车内各种总线网络，而且便于在车内引入新的电子控制系统。

对于亚洲汽车生产商来说，FlexRay标准化所带来的好处包括可削减开发和生产成本，降低采用这种创新性技术的风险，从而使这种新系统在市场中得到广泛采用。目前汽车中不同控制设备、传感器和制动器之间的数据交换主要是通过CAN网络完成的，但新出现的线控操作系统对于通信网络提出了更高的要求，特别是在消息传输的容错性和时间确定性方面。通过在固定时隙内进行消息传输，并同时利用两个通道提供消息传输容错和冗余机制，FlexRay 可满足这些方面的要求。

完全冗余系统

图1是一个汽车网络应用的例子，其中有四个车轮节点(1至4)、一个中央电子控制单元(ECU)(5)以及一个备份ECU(6)。在应用软件中采取适当措施后，一个ECU出现故障系统并不会受到影响。

然而简单的FMEA(故障模式和效果分析)提醒我们可能会出现更严重的故障，如水进入连接器导致连接到某个ECU的两个通道都出现问题、 ECU印刷电路板断裂或机械冲击使电缆固定套脱落或变形等等，这些都会导致两个通道出现同种故障模式(如图2)，使得某些节点的通信完全中断。

部分冗余系统

避免上述事故的一种方法是降低网络拓扑的复杂性。让我们回到熟知的两条独立对角线这一原则，那么可以得到一种可能的简单解决方案(图3)。

现在，车轮节点仅连接到一个通道，中央ECU及备份ECU仍连接到两个通道。ECU及其备份可以针对机械冲击进行更好的保护，因为可以将它们放在乘员单元，如中央控制台的后面。连线更少意味着故障模式更少，对有些应用这种解决方案可能适用，但上面提到的共同故障模式风险仍然没有消除，因此有必要寻求进一步的改进。FlexRay通过引入主动星型(active star)连接器来解决这一问题。

采用主动星型连接器的FlexRay系统

图4给出的网络拓扑与上面的类似，只是在一个通道中增加了一个主动星型连接器。

主动星型连接器作为一个路由器，在正常通信工作过程中将来自一个分支的输入消息发送到所有其它分支。主动星型连接器的好处是可以检测到出现问题的分支或者传输时间超过时间限制的消息，当检测到此类非法异常问题时，主动星型连接器会断开受影响的网络分支，从而保证网络中其它分支的通信不受影响。与其它物理层连接方式相比，主动星型连接器可断开出现故障的区域，这也是其最主要的优点。

假设结点6出现的故障影响到两个分支(图5)，系统仍然可以工作，尽管性能有所降低(但还是可以接受的)，当然节点2和3的通信会丢失。如果故障发生在节点5而不是节点6，那么情况也完全类似。这一结果非常有趣，因为仅仅在一个通道中使用了主动星型连接器，因此整个网络拓扑是非对称的。

采用两个主动星型连接器的FlexRay系统

在另一个通道中也引入一个主动星型连接器可使网络更为对称，同时在应用软件中采用相应的措施后，甚至在如图6的故障情况下系统性能也不会降低。此时，所有四个轮胎节点仍然处于可访问状态，中央ECU之一(这里是节点5)拥有对整个系统的控制。

当一个轮胎节点的线缆连接短路时，连接到这一对角线的另一个轮胎也会受到影响，在这样的故障模式下，这种网络拓扑与用一个主动星型连接器的网络相比并没有什么优势。然而对于有些应用同时有两个轮胎节点失去通信可能是无法接受的，这时就需要寻找一种不同的解决方案。其实也很容易找到，先连到短接线缆再连接至主动星型连接器的节点可以直接连接到主动星型连接器，这样每个主动星型连接器需要再多一个支路。

不使用短接线缆的FlexRay系统

与前面所讨论的所有故障模式相比，图7中的配置保证了最大网络可用性。顺便说一句，在本文所讨论的所有例子中，这种网络拓扑还提供了最好的电磁兼容(EMC)性，因为这里不再有短接线缆。