系统架构图和硬件架构图，有什么区别？

Automotive SPICE模型、ISO 26262标准里面的“System(系统)”，是指由Software, Hardware, Mechanical等相关学科构成的，能够在整车层面实现一定功能的对象。单独的Software或单独的Hardware，不能称之为“System(系统)”。

很多时候，在和项目组讨论System Architecture Design时，项目组在开始的时候都往往会说：“系统架构图就是硬件Block图啊！”

真的是这样吗？本文就这个话题进行讨论，也欢迎读者给出更多的观点和看法。

说明：本文后续描述中，假设构成系统的学科包括SW (Software), HW (Hardware), ME (Mechanical)。

系统架构设计

系统是由不同学科构成的，系统的实现需要不同学科共同来完成。那每个学科的职责是什么呢？学科之间的接口和交互是什么呢？这是系统架构设计需要解决的问题之一。

系统架构设计是对系统需求的Solution，主要包括：

• 识别系统元素，并确定其所属的学科。
• 将系统需求分配到系统元素，并据此识别系统元素之间的接口和交互。（即：系统元素与系统元素之间是如何来交互，从而实现的系统需求呢？）

项目在完成系统架构设计后，接下来就会进行各个学科的设计和开发。HW学科会据此分析硬件需求和进行硬件架构设计，硬件架构设计中会包括硬件Block图。

情况1：

​硬件Block图中的”硬件元素”与系统架构设计中”由HW实现的系统元素”是一致的，如下图所示：

这样的情况，表明了系统架构设计中包括了对硬件架构的限制。

不足之处也在于此：系统设计与硬件设计之间存在较强的耦合性。后续如果硬件设计发生了变更，则系统设计也需要变更。

这样的设计不符合“分层设计”、”低耦合度”等设计原则。

这样的场景，发生的可能条件，比如说：

• 没有专门的系统工程师，系统设计是SW、HW、ME等各个学科的代表共同完成的。
• 或者，系统工程师能力不足，没有足够的系统设计能力。

情况2：

​硬件Block图中的”硬件元素”与系统架构设计中”由HW实现的系统元素”之间，不存在一一对应的关系，如下图所示：

这样的情况，表明了在系统架构设计中，没有包括对硬件架构设计的限制，给硬件设计留足了设计空间。

这样做的好处：

• 系统设计与硬件设计之间不存在耦合性。（如果硬件设计改变了，系统设计可以不必修改）
• 这样的设计，符合“分层设计”、”低耦合度”等设计原则。

因此，好的系统架构设计：

• 应遵循相应的设计原则，例如：分层设计的原则
• 不应对各个学科的设计实现，进行不必要的限制，应给各个学科的设计和实现有足够的空间。（除非必要，否则不予限制）
• 系统架构设计中识别的由HW实现的系统元素，与，硬件架构设计中的硬件元素，可以不一一对应。
• 系统架构设计中识别的由SW实现的系统元素，与，软件架构设计中的软件元素，可以不一一对应。

推荐阅读：

• ​​Automotive SPICE和Automotive SPICE评估的那些事​​
• ​​如何达到并维持Automotive SPICE能力度级别​​
• ​​引入Automotive SPICE，企业要知道的二三事​​
• ​​引入Automotive SPICE，企业要知道的二三事（续）​​

文章转载自公众号：仨人谈起