嵌入式控制系统设计/设计流程
|
的维基教科书
嵌入式控制系统设计
|
本章描述了设计一个新的嵌入式系统，或改进一个现有系统的流程。也就是说，一个工程师，或一个工程师和项目经理团队如何以一种系统的方式来处理嵌入式系统的设计。本章试图不仅仅包含工程师对设计流程的看法：通常，一个流程从公司CTO（首席技术官）与客户（需求分析）讨论新产品的功能开始，然后HR（人力资源）和CFO（首席财务官）在第二阶段（高级设计）介入，以估计需要多少人和哪些人参与项目，以及它给公司带来了多少复杂性和风险。只有在那之后，工程师才能开始详细设计阶段，并开始考虑实现和测试。
尽管本书侧重于包含大量机械子系统的嵌入式系统，但设计步骤可能也适用于大多数其他工程领域的设计问题。
本章描述了设计一个新的嵌入式控制系统或改进现有系统的流程。也就是说，一个工程师或一个工程师和项目经理团队如何以一种系统的方式来处理设计。相对于对设计流程的传统看法，本章增加了一个额外的视角——每个特定系统的设计环境——以增进对传统设计步骤之间各种交互及其相对重要性的理解。最后一部分讨论了大型系统设计中的一些横截面问题。
文献描述了一组阶段或步骤，每个开发团队都将经历
- 系统辨识，理解过程并识别输入和输出之间的关系
- 需求定义，确定新产品或修改产品的需求或条件，同时考虑利益相关者（例如受益人、法律当事方或用户）之间可能存在冲突（技术、功能和非功能）的需求。
- 系统规范，描述系统所需的性能。
- 功能设计，定义系统中需要的子流程（或组件）。
- 详细设计，最终形成系统必须由其构成所有模块的具体结构。
- 实现，构建和测试最终系统的原型。
有些情况（例如这个例子）会经过所有这些阶段，但很难清楚地描述每个新设计要经历的确切阶段，以及设计团队在每个阶段应该做什么。有些设计会在功能设计阶段花费更多时间，而另一些会在系统规范阶段花费更多时间，等等。
市场要求交付越来越复杂的系统，以及越来越多的定制、终身维护支持以及系统使用寿命结束后的回收和拆卸要求，导致设计活动无法再遵循任何传统的、高度结构化的设计流程模型。除了可能在航空等领域，需要满足严格的规定和认证。
本节讨论一些流行的传统设计流程模型
- 瀑布模型是最严格的模型，建议只有在完成并完善了前一个阶段后才能进入下一个阶段。瀑布模型中的开发阶段被严格地分开，没有迭代或重叠的空间。
- V模型与瀑布模型具有相同的严格串行结构，但它建议在进入更详细的设计级别之前，应该先测试所有可以在当前设计抽象级别测试的系统功能和属性。
- 增量模型允许在某些设计阶段进行多次迭代，形成一个多瀑布过程。
- 螺旋模型类似于增量模型，更强调风险分析。螺旋模型有四个阶段：计划、风险分析、工程和评估。软件项目反复地通过这些阶段进行迭代（在这个模型中被称为螺旋）。
- 模型驱动工程是一种新兴的设计流程，它通过支持每个设计级别的测试阶段来改进V模型，这些阶段由软件模型模拟，这些模型在实际实现存在之前就模拟了系统。
在实践中，特定系统的设计流程不仅取决于要经历哪些阶段以及顺序，还取决于系统要被设计到的环境的具体情况：是否要制作一个已经成功的产品的下一个版本？是否要设计一个基于尚未成熟的技术的创新系统的第一个原型？是否要设计一个系统来参加比赛？等等。以下几节通过介绍一套（非详尽的）典型环境，将设计环境问题进行结构化。
在这种类型的项目中，设计团队从头开始工作，因此需要对所有内容进行组织和设计。这既是劣势也是优势：完成这些项目需要大量工作（时间和金钱），但整个系统可以设计得让每个组件都能与其他组件良好地交互。以Senseo咖啡机为例。该产品不是从之前的型号发展而来，而是从无到有设计出来的。使用的技术、基本原理、外观......所有这些都是全新的，并非来自旧款咖啡机（无论是来自飞利浦公司还是来自任何竞争对手）。
这种环境中的典型项目会按照图1所示的循环进行。从“需求定义”开始，可以由设计团队定义或从市场调查中推断出来，这个过程经历了越来越详细的级别。在“系统规范”、“功能设计”或“详细设计”步骤中出现问题，从而需要调整需求是很方便的。
另一个重要的步骤是测试或“实现”阶段。由于产品是全新的，因此应该对系统进行彻底的测试。错误消息的反馈在此阶段至关重要。这些原型也是架构设计或详细设计调整的来源。在极端情况下，甚至需要重新开发需求定义，例如当原型表明需求在物理上不可实现时。
所有这些迭代使得项目非常耗时。
设计团队通常会从其产品的先前模型、版本...入手，并试图通过减少缺陷和强调优点来改进概念。很明显，与从零开始相比，这些项目更节省时间。这种工作方法可以应用于几个版本，但存在使事情变得比实际更复杂风险。因此，有时重新开始是有必要的。
我们报告了存在不同适应性的事实。有时系统会扩展全新的功能，这可能从一两个设计需求的根本性变化到许多小调整不等。另一种适应性是对现有设计需求的优化。
在汽车行业，设计师通常在这种环境中工作。汽车制造商通常拥有几种型号，这些型号会随着最新技术的改进而改进，例如第一辆保时捷卡雷拉 911于 1963 年推出，但其概念仍然每隔几年更新一次。即使在开发新细分市场的新车型时，设计团队也可以重复使用旧的概念或组件，例如底盘。
图 2 显示，与从零开始的环境相比，参与的反馈或迭代明显减少。需求定义主要来自市场研究。客户被询问对当前产品的满意度和不足之处，以便公司能够解决这些缺陷。例如，在汽车行业，概念车首先会向公众展示。根据公众的反应，汽车制造商可以决定概念是否已准备好投入生产，或者是否还需要进行一些修改。
需要注意的是，并非所有需求都可以从市场研究中得出。例如，安全气囊不是直接从市场研究中得出的，因为你无法期望任何市场研究能得出这样的结果。在这种情况下，市场研究结果可能涉及安全缺陷。然后，工程师必须将这一需求转化为一个新系统。没有客户会说：“设计一个汽车碰撞时会爆炸的气囊”。
原型可能会迫使详细设计发生改变，因为所需的功能没有实现，但通常不会向系统规范进行迭代。
如今，维护（或售后支持）的方面变得越来越重要。在商品化的早期阶段，一个能用的产品就是一个好产品，但现在客户要求更高，如果一个产品设计不好，公司会在短期或长期内受到惩罚。因此，全面质量管理是一个有用的工具。
许多公司会组织比赛，获胜团队将被选中生产或建造提出的产品（例如，在建筑环境中）。这类项目的典型特征是截止日期以及由组织者制定的严格边界条件或规范。这些目标通常难以实现，导致设计师必须富有创造力和灵活。这通常需要迭代式的运作方式，第一个设计会经过多次修改才会完成。
这种环境的一个例子是机器人世界杯挑战赛。在这个比赛中，不同的团队试图建造能够踢足球的机器人。
在图 3 中，可以看到描述设计流程的循环。迭代参与了设计，但它集中在测试阶段。尽管概念、使用的技术和细节可能会频繁变化，但需求却非常坚定且不可替代（在图 3 中用粗体框架表示）。只有当这些频繁的转换不花费太多成本时，它们才被允许。更改驱动程序源代码中的某些参数不花钱，但更改系统中的硬件组件却要花钱！
设计师不会考虑系统的维护方面。产品应该满足需求，但不需要商业化或大规模制造。在某些情况下（例如，建筑竞赛），维护或耐用性方面可能是组织者定义的需求之一。在这种情况下，它显然不可忽略。
尽管研究通常与大学有关，但它是现代公司的一项重要活动（有时超过 20% 的销售额都会注入研发部门）。这类项目的最大特点是需求设置灵活。人们从一个既定的目标入手，并通过这样做，会找到相关项目，他们可以进行研究，并可能导致有趣的新发展。
例如，谷歌以其“20% 时间”而闻名。在这种理念中，所有谷歌员工都被鼓励将 20% 的时间（或一周中的一天工作时间）花在他们认为有趣的事情上。这样就可以发现许多以前没有想到的新领域。
与竞争环境相比，需求没有那么严格地概述。通过定义系统规范，通过寻找新的发展或分析原型，可能会出现一些有趣的新主题，这些主题会取代或补充之前定义的需求。
与竞争环境类似的是缺乏维护设计步骤。处理的系统没有商业目标，因此不需要考虑潜在的客户。一旦研究项目取得明确成果，公司决定将特定产品推向市场，这些步骤就会变得重要，项目将转移到从零开始或适应环境。一个在研究环境中的项目的良好例子是阳光动力。
通常很难结束这些项目，“继续研究是否有必要？”或“我们是否有足够的信息来构建新产品？”这些问题并不容易回答。在公司中，研发经理负责这些问题，就像他是决定哪些研究项目有趣，哪些项目不有趣的人一样。
- 研究环境中的设计团队通常专注于一个或两个用户需求。
- 关于这种环境的另一个重要问题是资金。例如，衍生公司一直在花费时间寻找愿意为其项目提供资金的人或组织。
本节讨论了所有设计步骤中相似之处或重要的项目。这些跨部门问题还涵盖了不同设计阶段之间的连续性。有关明显跨部门问题（即沟通、资源、质量等）的信息，可以在维基百科上找到。
一个好的设计会在尽可能长的时间内等待，直到填入实际组件和硬件。这为以后的实现留下了更多选择，从而为意外情况留下了更大的余地。
在设计流程中能够保持多长时间的广阔视野，通常很大程度上取决于市场。这个视野可以保持到将特定系统或产品与客户关联的点，这个点被称为订单渗透点。根据产品交付策略（库存生产、按需组装、按需生产、按需工程），这个视野可以在整个流程中保持广阔，或者在设计流程开始时就由最终用户确定。