嵌入式控制系统设计/设计过程

维基教科书

嵌入式控制系统设计

本章描述了设计新的嵌入式系统或改进现有嵌入式系统的过程。也就是说，一个工程师或一个工程师和项目经理团队如何在系统化方式中处理嵌入式系统的设计。本章试图将不仅仅是工程师对设计过程的看法纳入进来：通常，一个过程从公司的首席技术官（CTO）与客户讨论新产品的功能（需求分析）开始，人力资源（HR）和首席财务官（CFO）在第二阶段（高级设计）介入，估计需要多少人以及哪些人参与项目，以及它对公司的复杂性和风险有多大。只有这样，工程师才能开始详细设计阶段，并开始考虑实现和测试。

虽然本书重点关注包含大量机械子系统的嵌入式系统，但设计步骤可能也适用于大多数其他工程领域的设计问题。

引言

本章描述了设计新的嵌入式控制系统或改进现有嵌入式系统的过程。也就是说，一个工程师或一个工程师和项目经理团队如何在系统化方式中处理设计。相对于传统的设计过程观点，本章增加了一个额外的观点——每个特定系统的设计环境——以增进对传统设计步骤之间各种交互作用及其相对重要性的理解。最后一节讨论了大型系统设计中的一些横截面问题。

设计过程：预定义模式？

文献描述了一组每个开发团队都将经历的阶段或步骤

系统辨识，了解过程并识别输入和输出之间的关系
需求定义，确定满足新产品或更改产品的需求或条件，同时考虑到各种利益相关者（例如受益人、法律当事人或用户）可能相互冲突的（技术、功能和非功能）需求。
系统规范，描述系统要求的行为。
功能设计。定义系统中需要哪些子过程（或组件）。
详细设计，最终形成系统必须由所有模块组成的具体结构。
实现，构建和测试最终系统的原型。

有些案例（例如这个示例）经过了所有这些阶段，但很难明确描述每个新设计必须经历的阶段，以及设计团队在每个阶段应该做些什么。一些设计将在功能设计阶段花费更多时间，另一些将在系统规范阶段花费更多时间，等等。

市场对提供越来越复杂系统的需求，以及对定制、终身维护支持以及系统使用寿命结束后回收和拆卸要求的需求，导致设计活动不再能够遵循任何传统的、结构化程度很高的设计过程模型。除了可能是在航空等领域，需要满足严格的规定和认证。

传统设计过程模型

本节讨论了一些流行的传统设计过程模型

瀑布模型是最严格的模型，建议只有在完成并完善了前一个阶段后才能进入下一个阶段。瀑布模型中的开发阶段是完全分开的，没有迭代或重叠的空间。
V 模型与瀑布模型具有相同的严格串行结构，但它建议在进入更详细的设计级别之前，应该已经测试了可以在当前设计抽象级别测试的所有系统功能和属性。
增量模型允许在一些设计阶段进行多次迭代，从而形成一个多级瀑布过程。
螺旋模型类似于增量模型，但更强调风险分析。螺旋模型有四个阶段：规划、风险分析、工程和评估。软件项目在迭代中反复经过这些阶段（在这个模型中称为螺旋）。
模型驱动工程是一种新兴的设计过程，通过支持每个设计级别的测试阶段，通过模拟系统软件模型，在真实实现存在之前。

设计环境

在实践中，特定系统的设计过程不仅取决于要经历哪些阶段、以什么顺序进行，还取决于环境的特殊性，系统将在其中设计：是否要制作现有成功产品的下一个版本？是否要设计基于仍处于部分不成熟技术的第一代创新系统原型？是否要设计一个系统来参加竞赛？等等。以下部分通过展示一组（非详尽的）典型环境，为设计环境问题提供一些结构。

从零开始的环境

在这种项目中，设计团队从头开始工作，因此需要对所有内容进行组织和设计。这既是缺点也是优点：完成这些项目需要大量工作（时间和金钱），但可以以所有组件都能很好地交互的方式设计整个系统。以Senseo 咖啡机为例。这款产品并非来自以前的型号，而是从无到有设计出来的。使用的技术、基本原理、外观……所有这些都是全新的，没有从旧款咖啡机中借鉴（无论是飞利浦公司还是任何竞争对手）。

在一个典型的项目中，其设计流程遵循图1所示的循环。从“需求定义”开始，这可以由设计团队定义或从市场调查中推断出来，整个过程经过逐步细化。在“系统规格”、“功能设计”或“详细设计”阶段，如果出现问题，则需要调整需求，这十分方便。

另一个重要的步骤是测试或“实现”阶段。由于产品是全新的，因此应对其进行全面测试。此时，错误消息的反馈至关重要。这些原型也是调整架构或详细设计的来源。在极端情况下，甚至需要重新开发需求定义，例如，当原型表明需求在物理上不可实现时。

整个迭代过程使得项目耗时很长。

适应环境

在这种情况下，设计团队从其产品的先前模型、版本等开始，并试图通过减少缺点和强调优点来改进概念。很明显，与从头开始的项目相比，这些项目更加节省时间。可以使用这种工作方法进行多个版本，但存在使事物变得比应有的复杂。因此，有时重新开始是很有用的。

我们报告存在不同的适应方式。有时系统会扩展全新的功能，这可能从设计需求中的一两个重大改变到大量微小调整不等。另一种适应方式是优化现有设计需求。

在汽车行业中，设计师通常在这种环境下工作。汽车制造商通常拥有几个型号，这些型号通过最新技术进行改进，例如，第一辆保时捷卡雷拉911于1963年推出，但其概念每隔几年就会更新。即使开发了新细分市场的新车型，设计团队也可以重复使用旧概念或组件，例如底盘。

图2显示，与从头开始的环境中的设计流程相比，反馈或迭代明显更少。需求定义主要来自市场调查。客户会询问当前产品的满意度和不足，以便公司可以解决这些缺陷。例如，在汽车行业，概念车首先会向公众推出。根据公众的反应，汽车制造商可以决定概念是否已准备好投入生产，或者是否还需要进行一些修改。

应该注意，这些需求并非全部都来自市场调查。例如，安全气囊并非直接来自市场调查，因为你不能指望市场调查得出这样的结果。在这种情况下，市场调查结果可能涉及安全缺陷。然后，工程师必须将此需求转换为新的系统。没有顾客说过：“设计一个在汽车碰撞时会膨胀的气囊。”

原型可能会迫使详细设计发生改变，因为所需的函数无法实现，但是，向系统规范的迭代是不寻常的。

如今，维护（或售后支持）方面变得越来越重要。在商品化的早期，只要产品能工作，就是一个好产品，但现在，客户的要求更高，如果一个产品设计不好，公司就会在短期或长期内受到惩罚。因此，全面质量管理是一个有用的工具。

竞争环境

许多公司会组织竞赛，获胜团队将被接受生产或建造提议的产品（例如，在建筑环境中）。此类项目的典型特征是截止日期和组织者规定的严格边界条件或规格。这些目标通常很难实现，这使得设计师必须具有创造力和灵活性。它通常需要一种迭代的工作方式，第一个设计将在完成之前经过多次调整。

此环境的一个例子是RoboCup挑战赛。在这个比赛中，不同的团队试图建造一个能够进行足球比赛的机器人。

在图3中，可以看到描述设计流程的循环。设计中涉及迭代，但重点在于测试阶段。虽然概念、所用技术和细节可能会频繁发生变化，但需求是坚如磐石且不可替代的（在图3中用粗框表示）。只有在这些频繁的转换不花费太多成本的情况下才允许进行转换。更改驱动程序源代码中的某些参数不花任何钱，但更改系统中的硬件组件却需要花很多钱！

系统维护方面不在设计师的考虑范围内。产品应该满足需求，但不需要商业化或大规模制造。在某些情况下（例如，建筑设计竞赛），维护或耐用性方面可能是组织者定义的需求之一。在这种情况下，它显然不容忽视。

研究环境

研究虽然通常与大学有关，但却是现代公司中的一项重要活动（有时超过20%的销售额都投入到研发部门）。这类项目的主要特点是需求的灵活设置。从给定的目标开始，在做这件事的过程中，会找到相关项目，可以进行研究，并可能带来有趣的全新发展。

例如，谷歌以其“20%时间”而闻名。在这种理念中，所有谷歌员工都被鼓励将20%的时间（或一周中的一个工作日）花在他们认为有趣的主题上。这样就可以发现许多以前从未想到的新领域。

与竞争环境相比，需求没有严格的界定。通过定义系统规格，通过寻找新的发展方向或通过分析原型，可能会出现一些有趣的新的主题，这些主题会取代或补充先前定义的需求。

类似于竞争环境，维护设计步骤也缺失。所处理的系统没有商业目标，因此不需要考虑潜在的客户。一旦研究项目取得了明确的结果，公司决定将特定产品推向市场，这些步骤就变得重要，项目就会转移到从头开始或适应环境中。一个在研究环境中进行项目的很好的例子是阳光动力。

终止这些项目通常很困难，诸如“继续研究是否有效？”或“我们是否有足够的信息来制造新产品？”这样的问题并不容易回答。在一个公司里，研发经理要对这些问题负责，就像他要负责确定哪些研究项目很有趣，哪些项目没有趣一样。

研究环境中的设计团队通常侧重于一个或两个用户需求。
与该环境相关的另一个重要问题是资金。例如，分拆公司不断花费时间来寻找愿意为其项目提供资金的个人或组织。

交叉问题

本节将讨论所有设计步骤中重要的相似之处或项目。这些交叉问题还涵盖了不同设计阶段之间的连续性。有关明显交叉问题的资料（即沟通、资源、质量等）可以在维基百科上找到。

后期设计承诺

好的设计会尽可能长时间地等待，直到填充实际的组件和硬件。这为以后的实现留下了更多选择，从而为意外情况提供了更多余地。

在设计流程中，能够保持广阔视野的程度通常取决于市场。视野可以一直保持到某个特定系统或产品与客户联系的那一刻，这个点被称为订单渗透点。根据产品交付策略（备货生产、按订单组装、按订单生产、按需求设计），视野可以保持整个过程的广阔，或者从设计过程开始就由最终用户决定。