几种真实设计环境中的系统设计

几种真实设计环境中的系统设计

       Schirrmeister指出，这种理想化的过程非常依赖于两组其他的数据，但不能保证可以使用这些数据。首先是使用场景。在正确的使用场景中，我们可以限制对修改后的设计进行验证，特别是对用户比较重要的模式和输入。如果没有使用模型，我们需要确定新设计在所有可能的实际环境下都满足现有以及修改后的需求。

      其次是足够的测试台，针对整个系统和关键子系统。在实际中，测试台体现了人类语言文档无法表示的需求。很多设计团队认识到这方面的不足，重新建立系统测试台，这一项目规模与系统设计本身一样大——如果不能提供第三方SoC等关键元器件的数据，其规模会更大。

        在真实环境中

       对于一些设计人员组织而言，我们的理想化实例不一定具有可行性。汽车、交通、民用航空等领域的设计团队需要面对ISO 26262或者DO 178B等标准，要求设计和测试台中的每一单元都能够追溯到需求文档的控制单元。这些设计团队能够找到设计中的哪一部分需要进行测试，甚至进行修改以符合需求的变化。他们可以指出哪些模块需要在测试台中进行修改。这一开始就需要很大的投入。

      但是在大部分实际设计中，很难实现形式需求的可追溯性。这种项目的可追溯性只存在于设计团队成员的大脑中。即使最初的设计人员还能够说出，是什么原因让他以某种方式来实现某一模块，但是，在有人向他提问之前，他可能已经离开公司了，或者不在这一行业中了。我们不得不质疑我们的理想场景怎样应用在这些真实环境中。

       在一个平台上

       考虑设计团队使用平台设计的情况。平台一般是由SoC供应商提供的，是系统设计的扩展，而Android是个明显的例外。您要针对这一体系结构进行的尝试都含在规范中。概念非常简单。建立您自己的需求，找到您不需要的部分平台，不用它们(图3 )。然后，根据需要来优化其他部分，以满足参数约束。

图3.去掉部分平台，使平台设计满足特殊需求。

       但是这一概念也面临一些难题。首先，不一定有需求文档。因此，团队不得不猜测平台建立者的目的是什么，是否符合新需求。确定了不同点后，这就比较简单了。例如，Android能够适用于摄像机和麦克风。如果您并不需要这些，就可以把这些功能去掉。

     功能需求会更具挑战性。您可能需要一台摄像机来采集MPEG4视频。但是，您还需要四个ARM内核和一个DDR3 SDRAM接口吗?用户只是进行网页浏览，您还需要采集和压缩视频吗?使用模型和功能需求的缺乏会迫使您进行大量的系统级仿真，以发现哪些模块实际参与了您需要支持的工作。