随着嵌入式系统不断普及，我们可以从积累的开发知识中获得巨大优势，构建更出色的系统。E工程师一刻也没忘记交付达到质量、时间安排和预算目标的项目的需求。您可以借鉴嵌入式系统开发人员社区多年来累计的经验教训，确保您下一个嵌入式系统项目达成这些目标。下面我们来了解一些为嵌入式开发带来了最佳实践的重要经验。
系统地思考
系统工程是一个广泛的专业领域，覆盖从航空母舰及卫星到实现其性能的嵌入式系统的所有开发工作。我们可以运用系统工程方法管理从概念到使用周期结束处置的嵌入式系统工程生命周期。系统工程方案的第一阶段跟常人想象的不一样，，不是确立系统需求，而是制定系统工程管理规划。这一规划不仅将为系统定义工程生命周期以及开发团队将要开展的设计评审，而且还将定义这些评审的预期输入输出。该规划可根据工程事件的次序和每个阶段的先决条件，为项目管理、工程和客户群体做出明确的定义。简而言之，它可展示预期和可交付项。在清楚理解工程生命周期的情况下，系统思考的下一步是确立正在开发嵌入式系统的需求。良好的需求集应覆盖三个方面。功能需求定义嵌入式系统如何开展工作。非功能需求定义法规遵从与可靠性等方面的问题。环境需求定义工作温度和冲击与振动以及电气环境(例如 EMI 和 EMC)等方面的需求。在较大规模的开发工作中，这些需求将从较高层次的规范向下延伸并且可跟踪，比如系统或子系统规范(图 1)。如果没有较高层次的规范，我们必须在开发过程中接触利益相关方，确立一套明确的利益相关方需求，然后将其用于确立嵌入式系统需求。
生成一个良好的需求集,需要我们充分思考每一个需求，才能确保其符合这些标准：
1. 它是必要的。没有需求,我们的项目就不会取得成功。
2. 它是可验证的。我们必须确保该需求能通过检验、测试、分析或演示实现。
3. 它是可实现的。在给定的约束条件下,该需求在技术层面上是可以实现的。
4. 它是可追踪的。该需求能够从较低层次的需求进行追踪，而且可追踪较高层次的需求。
5. 它是唯一的。这项标准可防止需求之间的界限不清。
6. 它是简单清晰的。每条需求指定一项功能。
为体现意图，在定义需求时还常常使用特定语言。一般我们对强制性要求使用“必须”，对非强制性要求使用“应该”。非强制性要求可让我们表达必要的系统属性。
在我们确立了我们的需求底线后，最佳实践就是创建一个合规矩阵，说明符合每项需求。我们还可以通过为每项需求分配一种验证方法开始确立我们的验证策略。这些方法一般是测试、分析、检验、演示和交叉读取。根据合规及验证矩阵创建需求能让我们：
• 清晰地了解系统行为。
• 向内部测试团队和外部客户都演示验证方法。这不仅可在开发过程的早期阶段发现任何困难的测试方法，而且还可帮助我们确定所需的资源。
• 确定技术性能指标。这些指标来自合规矩阵，由存在无法合规的风险的各种需求构成。
分配工程预算
每个工程项目都涵盖一定数量的预算，我们应将其分配给在架构中识别的解决方案。预算分配不仅可确保项目实现整体需求,而且还可确保每个模块的设计牵头人理解模块的分配，以创建适当的解决方案。我们分配预算的典型领域有功能的总质量、功能的总功耗、用平均故障间隔时间或成功概率定义的可靠性以及设计中信号类型间的正当串扰(一般是一套适用于大量功能的通用规则集)。确立工程预算最重要的方面之一是确保我们有足够的应急分配。但我们必须战胜应急再加应急的想法，因为这会成为影响时间安排和成本的严重技术问题。
管理技术风险
从合规矩阵及工程预算的生成看，我们应该能够识别在技术上有难度的需求。每一个为在我们架构中使用的每项技术分配一个技术就绪指数，再结合合规矩阵，可帮助我们确定技术风险的所在位置。
这类有风险的需求都应该有明确的规避计划，其将说明我们将如何实现这一需求。展示这一点的最佳途径之一是使用技术就绪指数 (TRL)。TRL 有 9 级，从所观察到的基本原理 (TRL1) 到完整功能与实地部署 (TRL9) 描述设计成熟度级数。把 TRL 分配给我们架构中使用的每一项技术，再结合合规矩阵，可帮助我们确定技术风险的所在位置。我们随后可启动一个 TRL 开发规划，确保在项目不断推进时，低 TRL 领域会提升到所需的 TRL 水平。该规划涉及的内容可确保我们在项目推进时实现和测试正确的功能，或是在项目推进的过程中执行功能或环境/动态测试。
该架构不应仅限于硬件(电气)解决方案，还应包含 FPGA/SoC 及相关软件的架构。
创建架构
理解嵌入式系统要求的行为后，我们就需要为解决方案创建一个架构。该架构将由分组成功能块的需求构成。例如，如果嵌入式系统必须处理模拟输入或输出，架构就将包含模拟 I/O 模块。其它模块可能会更加明显，比如电源调节、时钟和复位生成。
该架构不应仅限于硬件(电气)解决方案，还应包含 FPGA/SoC 及相关软件的架构。当然，模块化设计的关键是针对模块及功能行为的良好接口文档编制。
该架构的一个关键方面是展现如何在高层次上创建系统，这样工程团队就能轻松理解其实现方式。该步骤也是在系统运行生命周期中为系统提供支持的关键。
在确定我们的架构时，我们需要考虑模块化方法，这样不仅能在当前项目上进行复用，而且还能在未来的项目上进行复用。模块化要求我们从第一天起就考虑可能的复用，并要求我们把每个模块存档为一个独立的单元。就内部 FPGA/SoC 模块而言，像 ARM® AMBA® 高级可扩展接口 (AXI) 这样的通用接口标准有助于实现复用。
模块化设计的一个重大优势就是能够针对某些需求使用商用现成的模块。商用现成(COTS)模块让我们能够以更快的速度开发系统，因为借助 COTS，我们能够把我们的工作重点放在项目从我们的专业能力产生的增值中获益最大的部分上。
系统电源架构是一个需要缜密思考的的设计方面。许多嵌入式系统会要求隔离 AC/DC 或 DC/DC 转换器来确保嵌入式系统的故障不会扩散。图 2 显示的是电源架构的示例。来自该模块的输出轨需要二级调整来为处理内核和转换装置提供电压。我们必须仔细防范这些阶段发生严重的开关损耗和效率下降。因为效率降低意味着系统热耗散增大，如果不正确解决就会影响单元的可靠性。
我们必须仔细了解使用的线性调整器的行为以及在电源线上进行进一步滤波的要求。这一要求的原因是 FPGA 和处理器等器件的开关频率远远高于线性调整器的控制环路所能应对的水平。随着噪声频率提高，线性调整器的噪声抑制能力下降，导致需要采用额外的滤波和去藕技术。如果不了解这一关系，会造成混合信号设备出现问题。
另一个重要的考虑因素是时钟和复位架构，尤其是在有多个需要同步的开发板的情况下。在架构层面我们必须考虑时钟分配网络：我们是否在跨多个开发板扇出单个振荡器，或是使用多个频率相同的振荡器?为确保时钟分配的稳健可靠性，我们必须考虑：
• 振荡器启动时间。我们必须确保在整个时间周期内激活复位(如果需要)。
• 振荡器歪斜。如果我们要在跨多个开发板扇出振荡器，时序是否至关重要?如果是，我们需要考虑线路卡上的歪斜(连接器引起的)和缓冲器自身引起的歪斜。
振荡器抖动。如果我们在开发混合信号设计，我们需要确保使用低抖动时钟源，因为抖动的增大会降低混合信号转换器的信噪比。在我们使用千兆位级串行链路时情况也是一样，因为我们需要使用低抖动时钟源在链路上取得良好的误码率。
我们也必须注意复位架构，确保只在需要的地方使用复位。例如基于 SRAM 的 FPGA 一般不需要复位。
如果我们在使用复位的异步激活，我们需要确保移除它不会导致亚稳态问题。
清晰定义接口
内外部接口的正式文档在机械、物理和电气层面为各个接口提供清晰的定义，以及协议和控制流。这些正式文档也往往被称为接口控制文档 (ICD)。当然最好是尽量使用标准通信接口。
接口定义最重要的一个方面是外部接口的“连接化”。这个过程考虑了所需连接器的引脚分配，连接器引脚的额定功率以及所要求的插拔次数，以及任何对屏蔽的要求。
在我们为我们的系统考虑连接器类型的时候，我们应确保不会因为在子系统中使用相同类型连接器而造成不利的交叉连接。通过使用不同类型连接器或采用不同的连接器键位(如果支持)，我们就能够避免交叉连接的可能性。
连接化是我们开始使用之前确定的预算要求的首个方面之一。特别是我们可以使用串扰预算来指引我们定义引脚分配。图 3 所示的例子说明了这一流程的重要性。重新安排引脚分配，将接地基准电压 (GND) 引脚布局在信号 1 和信号 2 之间，可以降低互感以及由此引发的串扰。
接口控制文档 (ICD) 必须对系统接地进行定义，尤其是在项目要求外部 EMC 的时候。在这种情况下，我们必须小心避免让有噪声的信号地产生辐射。
工程师和项目经理掌握着一系列策略，以确保他们交付的嵌入式系统能够满足质量、成本和调度要求。不过当项目遇到困难时，我们可以确信在项目不发生重大变化的情况下其此前的性能是其未来性能的良好提示。
