借鉴开发人员累计的经验教训构建更出色的嵌入式系统

随着嵌入式系统不断普及，我们可以从积累的开发知识中获得巨大优势，构建更出色的系统。

工程师一刻也没忘记交付能同时满足质量、时间安排和预算目标的项目的需求。一个事半功倍的方法 就是借鉴嵌入式系统开发人员社区多年来累计的经验教训。下面我们就来了解一些为嵌入式开发带来了最佳实践的重要经验。大家随用随取哈。

系统地思考

系统工程是一个广泛的专业领域，覆盖从航空母舰及卫星到实现其性能的嵌入式系统的所有开发工作。我们可以运用系统工程方法管理从概念到使用周期结束处置的嵌入式系统工程生命周期。系统工程方案的第一阶段不是确立系统需求，而是制定系统工程管理规划。这一规划不仅将为系统定义工程生命周期以及开发团队将要开展的设计评审，而且还将定义这些评审的预期输入输出。该规划可根据工程事件的次序和每个阶段的先决条件，为项目管理、工程和客户群体做出明确的定义。简而言之，它可展示预期和可交付项。

在清楚理解工程生命周期的情况下，系统思考的下一步是确立正在开发嵌入式系统的需求。良好的需求集应覆盖三个方面：

功能需求定义嵌入式系统如何开展工作。

非功能需求定义法规遵从与可靠性等方面的问题。

环境需求定义工作温度和冲击与振动以及电气环境（例如 EMI 和 EMC）等方面的需求。

在较大规模的开发工作中，这些需求将从较高层次的规范向下延伸并且可跟踪，比如系统或子系统规范（图 1）。如果没有较高层次的规范，我们必须在开发过程中接触利益相关方，确立一套明确的利益相关方需求，然后将其用于确立嵌入式系统需求。

 

图 1：在开发工作中，需求从较高层次的规范向下延伸并且可跟踪

生成一个良好的需求集,需要我们充分思考每一个需求，才能确保其符合这些标准：

它是必要的。没有需求,我们的项目就不会取得成功。

它是可验证的。我们必须确保该需求能通过检验、测试、分析或演示实现。

它是可实现的。在给定的约束条件下,该需求在技术层面上是可以实现的。

它是可追踪的。该需求能够从较低层次的需求进行追踪，而且可追踪较高层次的需求。

它是唯一的。这项标准可防止需求之间的界限不清。

它是简单清晰的。每条需求指定一项功能。

为体现意图，在定义需求时还常常使用特定语言。一般我们对强制性要求使用“必须”，对非强制性要求使用“应该”。非强制性要求可让我们表达必要的系统属性。

在我们确立了我们的需求底线后，最佳实践就是创建一个合规矩阵，说明符合每项需求。我们还可以通过为每项需求分配一种验证方法开始确立我们的验证策略。这些方法一般是测试、分析、检验、演示和交叉读取。根据合规及验证矩阵创建需求能让我们：

清晰地了解系统行为。

向内部测试团队和外部客户都演示验证方法。这不仅可在开发过程的早期阶段发现任何困难的测试方法，而且还可帮助我们确定所需的资源。

确定技术性能指标。这些指标来自合规矩阵，由存在无法合规的风险的各种需求构成。

分配工程预算

每个工程项目都涵盖一定数量的预算，我们应将其分配给在架构中识别的解决方案。预算分配不仅可确保项目实现整体需求，而且还可确保每个模块的设计牵头人理解模块的分配，以创建适当的解决方案。我们分配预算的典型领域有功能的总质量、功能的总功耗、用平均故障间隔时间或成功概率定义的可靠性以及设计中信号类型间的正当串扰（一般是一套适用于大量功能的通用规则集）。确立工程预算最重要的方面之一是确保我们有足够的应急分配。但我们必须战胜应急再加应急的想法，因为这会成为影响时间安排和成本的严重技术问题。

为在我们架构中使用的每项技术分配一个技术就绪指数，再结合合规矩阵，可帮助我们确定技术风险的所在位置。

管理技术风险

从合规矩阵及工程预算的生成看，我们应该能够识别在技术上有难度的需求。每一个这类有风险的需求都应该有明确的规避计划，其将说明我们将如何实现这一需求。展示这一点的最佳途径之一是使用技术就绪指数 (TRL)。TRL 有 9 级，从所观察到的基本原理 (TRL1) 到完整功能与实地部署 (TRL9) 描述设计成熟度级数。把 TRL 分配给我们架构中使用的每一项技术，再结合合规矩阵，可帮助我们确定技术风险的所在位置。我们随后可启动一个 TRL 开发规划，确保在项目不断推进时，低 TRL 领域会提升到所需的 TRL 水平。该规划涉及的内容可确保我们在项目推进时实现和测试正确的功能，或是在项目推进的过程中执行功能或环境／动态测试。

 

图 2：在本电源架构示例中，模块的输出轨需要二级稳压。

该架构不应仅限于硬件（电气）解决方案，还应包含 FPGA/SoC 及相关软件的架构。