架构设计到底在做什么？这个好像不应该成为问题，因为每个人都会回答：架构设计就是设计架构呗。然而，设计架构又是设计什么东西呢？

让我们先回顾一下以前聊过的一个话题：什么是电子电气架构。在以前的一篇文章中，我们讨论过架构的概念：架构是基于复杂系统的一个概念，体现的是系统之内的元素的基本结构和关系，是一种系统设计和演进的原则。

对于汽车的EEA（Electronic Electrical Architecture）来说，定义的就是汽车上电子部件之间的相互关系，及所有的电子部件（包含硬件实体及其中的软件）所共同承载的逻辑功能之间的关系，以及为了设计和维护这些电子部件所规定的各种原则。

从上面这个定义中可以看出，架构并不是一个具象化的实体，而是一个抽象的东西，任何一种具象化的东西都没有办法完整的表示出什么是架构。而且，架构一定是依赖于系统而存在的。

汽车的电子电气架构EEA依赖的就是汽车上的电子电气E/E系统。谈到EEA，一定离不开这个E/E系统。架构是系统的架构。

网络拓扑是架构的一部分，电气拓扑也是架构的一部分，但是它们都没有办法来代表完整的架构。它们所表示的仅仅是EEA的一部分特性或者属性。

接下来，让我们从城市的设计建造过程来理解E/E系统的开发工作以及EEA设计的工作。

虽然我以前曾经以一个大楼的设计、建造过程来解释过EEA设计的工作，可是从事EEA的工作越久，就越觉得汽车上EEA设计的复杂。由于现代车辆本身的高度复杂性，整车电子EEA设计更像城市规划。

假如我们从零开始规划一个城市，城市规划师首先要做的工作是确认需求：这个城市将来要住多少人、这些人以什么产业做为主要的生活来源，以及城市周边有多少可用的自然资源和与其他周边地区的关系等等，并且要搞清楚重要的一个事情：有多少预算。这个过程就像我们的EEA架构师要首先搞清楚老板想要造一个什么样的车、要卖给谁一样。

搞清楚需求之后，就是要规划每个街区的功能与规模，并确定街区之间的连接关系。比如，火车站在哪个位置，能够容纳多少的旅客与货运吞吐量容量，居民区、商业区、工业区与休闲区在哪个位置，能够容纳多少人等等。除了这些位置、功能与规模的设计之外，架构师还要详细的设计整个城市的内部有多少条公路、多少条地铁、每个地铁有多少个站点，并估算城市的电力、水等消耗情况，从而对供电和供水等基础设施进行规划。而且还要考虑城市与与外界的连接，包括铁路、公路、水运以及航空等。

1. 架构设计=城市规划

对于城市规划师来说，他们的设计对象并不是某一个街区或某个建筑，而是整个城市，他们要对整个城市的设计质量负责。如果我们如果把汽车上每个控制器甚至电子部件都想象成城市中的一个特定功能区域，那么电子电气系统的架构师做的就是规划整个的E/E系统，并对E/E系统的设计质量负责。

架构师首先要确定E/E系统（整个城市）的主要功能和性能，然后根据确定的功能与性能的目标来规划整车的拓扑（城市的街区）：确定有多少个主要的控制器、每个控制器的基本功能和相互的连接方式、车辆的主要通信网络的形式（CAN或者以太网或其它）等，并要设计整车的电源方案等。

因为E/E系统在车上并不是一个孤立的系统，它要与车辆本身的物理架构充分的融合，并与车辆的外部世界也有着密切的联系，所以，在进行E/E系统的规划时，他们还要考虑车辆本体的很多具体限制与能力，就如同城市规划师需要考虑城市的地形、气候以及与其它城市之间的关联性一样。每个控制器在车上的大致布置位置、质量要求、性能要求等也是需要在架构设计阶段需要考虑并确定的。

上述的各种架构设计阶段所确定的各种详细信息终会以各种原则、规范、标准或者需求等形式输出给相关方，他们会根据得到的需求来进行详细的设计，然后再交给终承担具体实现任务的各个供应商进行部件的开发。

2 .系统开发=街区设计

对于一个城市来说，每个街区的功能都是不同的，比如说可以分为商业区、居住区、工业区等等。因为每个街区的功能不同，所以它们的设计要求也不同。例如：居住区要能够容纳100万人，并有各种便利的生活设施，而工业区要能够支持多个大型的工业项目的生产、物流等要求。当某一个街区的设计要求由城市规划师确定之后，一般会有专门的人员进行详细的设计。例如：负责居住区的设计师把城市规划师的要求可以细化为：1000栋高20层的楼、有3所小学、两座医院等等，并详细的在图纸上列出它们的位置和边界，并对区内的交通网络、通信、电力网络等进行详细的设计，并给出具体的要求。这个过程可以类比为E/E系统中的系统设计。

车上的E/E系统也会被分为多个域或者子系统，每个域或者子系统的功能与技术要求都是不同的，比如：底盘控制、仪表显示、电池管理等。所以一般都会由来自专业领域的系统工程师来负责进行详细的设计。他们会像街区的设计师一样，根据架构设计的要求对自己所负责的领域进行详细的设计。灯光控制的系统工程师会根据车辆的配置和功能需求来设计灯光系统的详细逻辑以及具体的信号交互、硬件驱动的参数要求，并且给出对每个相关部件的详细要求，从而让各个部件的工程师能够完成对部件的详细设计。

3. 零部件设计=建筑设计

当街区的设计完成之后，接下来要做的就是每栋建筑的详细设计，建筑的设计者发布的图纸中规定了房屋的主要结构、所在位置与周边环境的相互关系，以及屋中各种组件的位置与相互之间结合的关系，比如砖混结构、房屋的具体位置和朝向、卧室与客厅的相对位置与尺寸、马桶在卫生间中的位置等，还会对各种建筑材料的选取原则给出具体的标准，比如水泥的标号，钢筋的型号，各种电线的等级要求等等。

零部件工程师完成的也是类似的工作，他们会和供应商进行深入合作，在满足系统工程师给出的具体要求的前提下，进一步详细的设计每一个具体的零部件，完成诸如硬件、软件逻辑的详细设计、整个零部件的外观尺寸、可靠性和EMC标准等，并要确保供应商的产线能够保质保量的稳定生产，随时解答供应商的各种问题，并将其中的部分问题反馈给系统工程师乃至架构师，让他们决定是否要更改原来的设计。

4 供应商开发=施工实现

在各种设计需求终到达供应商的时候，供应商就要开始具体的实施工作了。

在建筑行业，施工单位拿到具体的图纸之后，将组织施工队伍进行具体的建造工作，并终在验收完成后结束一切具体的工作。而汽车行业的供应商则有所不同，他们将在设计验收之后开始大规模的量产活动（SOP，Start Of Production），并且一直持续到产品退市（EOP，End of Production）。而且，对于很多复杂的产品，整车厂与零部件供应商的设计职责之间的界限并没有那么清晰，很多时候，整车厂只要给出概要性的设计，所有的详细设计工作都由供应商来完成。

从整个E/E系统的开发实现过程中可以看出：无论是架构设计、系统设计还是零部件的设计，其实都是设计的过程，而设计本身是一种不断产生需求、传递需求的活动，上下游之间的信息传递过程是以需求作为载体的，设计过程产生的各种规范、原则、标准等本质是一种需求——一种需要下游来遵守或满足的需求。需求的传递并非完全是瀑布式的单向传递，而是双向的，只有被下游接受了的需求才是有效的需求，而且，下游是可以反向对上游提出需求的。具体需求的终实现则是通过供应商的开发、验证和生产活动完成的。

一个主机厂的Knowhow究竟有多少，就看他们给出的规范有多少就足够了。

5 架构设计的重要性

无论施工队的技术多么高超，可是一个城市终的质量一定与规划师的设计质量息息相关。谁都无法否认一个好的设计对终交付物的重要性。

虽然规划师不需要参与到终的施工过程中，但是一个不懂施工的规划师是很难做出好的设计。规划师在进行架构设计的时候不可避免的也要了解很多具体的待实现组件的细节，比如：当地的地形地面、气候、风土人情、产业结构等等。对细节的关注是规划师必须具备的能力也是必须的工作。对于E/E架构的设计也存在着同样的要求，一个架构师如果不知道具体的零部件的复杂性与实现的细节，是没有办法设计出真正可用性高的架构的。从这个角度来讲，架构设计的工作既是顶层设计，但又不仅限于顶层设计。

就像城市的功能要不断的升级一样，E/E系统架构也要不断的更新以满足各种新的需求。E/E系统在产生后就像一个生命体一样，它自身的迭代成长是一个不会停止的过程。即使一个架构被历史淘汰了，但是它的一些基因（逻辑设计）还是会被继承到新的架构上，继续的存活下去。

一个好的架构设计可以保证成本、性能、功能等的平衡，并能让系统可以有良好的演进性。这个工作的重要性就跟城市规划的重要性一样：好的城市规划可以让城市以较低的成本就更适宜居住，并能在城市的规模扩大的时候不至于大幅度的进行改造才能满足日益增长的各种需求。然而，所有的规划都是有局限性的，没人可以预测50年或一百年以后的情景，就如同二百年前的城市规划师不会预测到有地铁出现一样，E/E架构与城市的设计同样需要不断的进行革新和演进。

为了能够让E/E系统可以顺利开发出来，尤其是对于全新的EEA，新的开发流程、组织架构的匹配是整个主机厂必须要进行匹配的配套设施。没有好的流程和组织进行匹配，新的EEA发挥的作用是有限的。想让一个EEA成为可以成长的、迭代的EEA，流程与组织的成长和迭代是前提。

而如何来设计这些新的开发流程，EEA的架构师往往是当仁不让的主力，他们应该清楚什么样的流程才能适配新的架构。从这一点来说，EEA架构师不应该只是EEA的架构师，他们还应该承担起企业架构师的部分职责。这还因为EEA承载着企业未来希望，更是一个动辄投入要几个亿甚至几十亿的宏大工程。

另附——架构师应具备的8项能力：

1. 对行业趋势、公司战略和目标的深刻理解

2. 健全的独立思考能力，敏锐的价值判定能力

3. 很强的语言表达能力（注意不是口才）：能跟老板讲明白技术，能把公司理念翻译成工程师们可以理解的语言。

4. 有一定的影响力和业务领域内的权威性。

5. 能根据公司战略制定技术方面的战略，并将其分解为指导思想和原则，并坚定的在工作中落实。

6. 具有高度的抽象和概括能力，能够迅速的找到复杂事物的本质，并可以给出解决复杂问题的办法。

7. 为开发团队、以及相关产品团队设计流程和标准。

8. 根据实际操作情况，对以上内容不断优化和调整。