反向工程的世界里，不需要系统设计。但一旦我们想搞些有趣的东西但又没东西可抄的时候，就来到了系统设计大师的天下。
反向工程的世界里，不需要系统设计。但一旦我们想搞些有趣的东西但又没东西可抄的时候，就来到了系统设计大师的天下。
1.系统设计的「能」与「不能」
系统设计本身不是一门科学，而是精妙至极的应用工程。但是，有精深科学素养的人或是组织，有较高的可能性会做出更厉害的系统设计。
达文西在500年前就发明了直升机，这种发明是基于系统设计的功底，及相比同期科学家理解更加深刻的科学原理（伯努利原理）。然而，在达文西的那个年代，纵然他有那個本事与想法設計出飛機，卻沒有足夠的平台支援他開發出一架能用的飛機：因為很多配套的基本技術都尚未成熟。這種与现实背离到一定程度的系统设计，可以说是系统设计的「不能」：它超越时代太多，以至于无法实现。
伟大的系统设计，或大或小，都面临过这种「不能」的窘境。当初贾伯斯要开发第一代iPhone时，面临的系统设计瓶颈就是可行的触碰屏幕方案；特斯拉早期全心致力于电动车开发，面临的系统设计困难就是电池与电机的成熟度问题。
划时代的产品通常都与当下能达成的系统设计能力有关：Porsche的911与一般车辆或跑车有何不同？答案就在它独特的系统设计：后置发动机。早期的后置发动机是个缺点，但带来了不一样的驾驭感受。然而经过了几十年的系统设计演化：如加入了后轮转向；利用水平对卧发动机设计降低重心位置……等等，后置的911成为了一款杀弯神器，能够用更低的马力输出叫板超跑的性能。
现今特斯拉达成的一些系统设计方案，也成为各家仿效的样板，其中的EE架构更是如此。透过高度的集成性，来达成降低成本与减少开发接口复杂性的目标。这是一种系统设计的颠覆，颠覆掉过去几十年间OEM大量仰赖供应商所形成的盘根错节分布式开发。回归中央集权，也代表OEM的系统设计规划能力，知识经验累积，与话语权都得同步提升到一个新境界。
总结一下，系统设计的「不能」，主要来自于与现实的脱节；而系统设计的「能」，则是带来时代与环境的技术迭代。
系统设计是个威力巨大的武器，若握在有想法的人或组织手上，便会产生许许多多的杀手级产品。
2.真实世界的系统设计
在国内的汽车业环境里，系统工程师常常是一个比较鸡肋的存在：一不写代码；二不画PCB，这样的工程角色似乎对开发提供的帮助不大。甚至在笔者的一些项目经验里，会发现公司指派相当资浅的人来担任系统工程师的角色。其实指派一个缺乏经验的人担纲系统工程师，能起到的作用大概就两个：能有个人协调组织并跟进开口项；再者就是如果这个人的资质不错，公司能在他担任系统工程师的期间培养他对产品开发方方面面的全局观，方便他未来跳槽到更好的工作上……（笑）
系统设计最美妙的地方实为：它让一个事物能从最抽象的概念落实到可开发的阶段：如，「飞在天上」是一个概念，但让这件事得以实现的是系统设计的方方面面：
- 设计的起点是想办法应用Bernoulli Principle来产生上浮力（功能需求）
- 当下技术使用机翼来承载Bernoulli Principle所产生的上浮力（架构需求）
- 当下技术使用发动机来创造高速流动空气（架构需求）
- 当下技术利用改变机翼迎风面来调整机身姿态（功能+架构需求）
如笔者前章节所述，系统设计的基础本质是应用科学，所以一个好的系统工程师必定会对当下技术的沿革比较清楚，如最新的机构设计与功能；最新可以用的接口与特性；最新的控制算法……对这些新技术的广泛与深入了解，才能为系统设计架构师提供充足的弹药。笔者在2016年的时候曾经在Silicon Valley与NVIDIA的一群人工智能领导或工程师讨论，他们提及GPU在ADAS上的应用，最早是2005年从Audi车厂那里提出来的建议，Audi工程师说到GPU或许可用于机器学习，而机器学习或可用于ADAS的影像识别。依笔者之见，这就是一个好的系统架构师在干的事情，随时在狩猎可用于实现特定目的的解决方案。
好的系统设计，必定会有一到多个solution；好的系统架构师，也必定会知道这些solution是啥，以及这些solution带来的后果为何。
既然solution才是系统设计的核心，而非function本身。我们或许可以下一个结论：
系统设计的两个可能方向是：科技发展先提供了solution，再由系统架构师找到了这个solution的使用方式，用于合适的use-case （如早期GPU与ADAS的关系）；或是系统架构师定义了function与架构要素特性后，再推导发明出合适的solution（如过往Bosch发明开发出了发动机的点火线圈）
这里也就得提到了汽车业二阶供应商的重要性：若说过去的世界一阶供应商是在定义及集成系统；二阶供应就是在供应各种solution building block
没有好的二阶供应商支撑（如uC; SoC…etc），无法为系统迭代提供源源不绝的solution开发及创新能力，再棒的系统设计都是白搭。或许这也是为何Tesla要把SoC的设计能力建立起来，它也想要保证能够一直把最有竞争力及最合适自己系统架构的solution控制在自己手上。
3.系统设计者的理想国 自上而下的绝对统治权
系统设计的精华在于架构设计，架构设计的精华在于对细节设计的纵观理解。笔者在参与国内主机厂多年项目经验后得到的深刻体会是：绝大多数主机厂工程师都在追求自上而下设计的绝对统治权。
这是一个丰满的理想。要实现这个理想，背后意味着：系統架構設計師要對設計標的物的細節能有充分的了解，這種了解若不是基于数十亿年的演进逐步深化（笑），就是基于大规模深刻的调研与对标后所形成的完整全貌思维。
相较于先前章节提及的，系统工程人员在绝大多数项目中被认为是鸡肋的角色，真实原因是大多数我们在世界上能看到的系统都已经有成熟的参考例，如果复杂性不大高，做做反向工程就能有不错的成果。注意，仍然存有看似简单的系统，里面可能暗藏玄机的关键组成单位（如精度极高的螺丝），如果我们在反向拆解系统时不能识别这些玄机（如关键需求；或关键核心技术），我们做出来的东西永远就是味道不对。
然而，任何时代皆相同，真正划时代的产品推出，背后都有着居功厥伟的系统规划师：小从第一台真空管计算机；大到未来的量子计算机，这个关键产品经理，其实就是一个重要的系统架构师，他要有着丰富的知识，因为他的工作就是一连串关键技术决策，与制定能实现的技术蓝图。当他在目标产品上的知识越丰富，资讯越正确，他就能比别人更好的规划与定义这个产品，甚至在别人想不到的创新领域，推出革命性的应用。是的，系统架构人员是为了应用而存在，他的输出应该直接在人类的生活层面提供了改善之处。
所以系统架构师或多或少都有些独裁性格：他应该清楚这个应用该实现的目的，并用各种手段（实现方案）来完成这个目的，所有的组成模块都仅是为了服务这个目的（高内聚），模块的行为也必须服从指定的行为（需求追溯性）。
然而，问题是，若这样自上而下的设计定义过程欠缺了关键知识与要素，它很可能就会成为一个看似逻辑自洽但大错特错的产物。此种案例，人类世界也不遑多让。
4.来看看我们的案例
这里来聊一些我看过比较有趣的系统设计问题：
系统设计第一个要打通的环节，就在于这个应用到底会在现实世界中出现怎样的互动。如早期特斯拉推出颇具个性的cyber truck，它或许已经预料到风阻的问题（反正车子也不必开快），但它没料到这样的曲面与材料组合可能会让玻璃被一砸就破。
越是积极投入在创新性的系统设计上，就会越发让人了解自己的不足，与对世界认知的不够深刻。我打赌，现在世界开始流行的L4自动驾驶不装方向盘与油门制动，待一旦开始跟真实世界密切互动后，我们肯定又会发现一些我们原本不知道的事：诸如对人类行为假设的错误；或任何跟其他车辆运动有关的议题。
系统设计必不可分的需要跨过理论假设与现实检验的收敛环节，事实上任何有形产品或无形制度都必须跨过同样的环节，差别只在于系统设计需要碰触到的宇宙面向更多：如Elon Musk在设计能到火星的星舰，必定会遇到我们平日系统设计更多的现实问题：如各式样我们平日可能不需要考虑的宇宙射线；或者遭遇潜在的陨石撞击……等等
这也推导出一个必然的结论：一个真正完备的系统设计，除了有严谨自上至下宰制思维，也必然有广阔地自下而上资讯采集系统，才能双向打通并凝成够牢固的系统级产品，带领星舰成功安全抵达火星。
谈到自下而上的突变式系统设计，就不得不谈软件定义汽车时代的显学：Service-Oriented Architecture（SOA），基于服务的架构。
SOA在汽车业上开发应用的美妙之处，在于我们已经具备了所有能用的HW solution：所以它是一个完全着重在软件solution及应用想法上的技术。而这些提前具备的底层硬件能力，原本是为了某个自上至下定义好的系统功能服务，但透过SOA技术的支撑，其他原本没有被定义好的系统功能，也能透过自下而上的方式整合突显出来。
一个简单的类比是：到底是从能量中裂变出了正物质与反物质（自上而下的演变）？还是正反物质的结合产生了能量（自下至上的组合）？
5.SOA为汽车业带来了些啥？
SOA是IT业的产物，那个世界没有太多高深的系统设计需求，一切就是求快跟方便。但SOA一旦撞上了讲究系统设计的汽车业，或许会跟美学撞上了科技于是诞生了iPhone一般，出现令人耳目一新的变种。
系统设计与SOA相同的地方，都在于讲究体现出来的功能或效果。但差异之处在于：系统设计必须考虑许多不同的集成要素（如机构；电控；硬件与软件），而SOA需要考虑的集成要素只有各层级的功能（或服务）而已。这种情况下，笔者认为SOA的最大价值在于把SoSE（System of Systems Engineering）的架构彻底在汽车业应用开来。
在汽车业的这个年代谈SOA，确实挺有意思，若是在10年前来谈，SOA能突变出来的新系统功能或许不会太多：因为底层能力带来的变化性不会很大。
在笔者刚于汽车业服务的时候，我们描述整车的行为常称其为“功能”；一段时日之后，它又被称作“特征”（feature）：不管是功能还是特征，它们多半是自上至下的方式被定义出来。然而，就在这两年，专业术语又变成了“服务”（service）
笔者可以试着简单类比下这几个上位的设计概念彼此间有何不同：若我们把“人”作为一个完整系统来说，它的规格书里面可能会定有以下几种内容：
- 系统功能：两双可以自由三百六十度移动与伸缩的手，每双手的五根手指也能自由活动收缩
- 系统特征：系统可以从事所需的搬运与精密控制活动
- 系统服务：任何透过手的使用能达成的技能，如：打篮球（运球；投篮）；打网球（握拍）；弹钢琴……等等
由上方的类比介绍，我们可以粗略窥见以下特性：“系统功能”通常与系统配置的硬件强绑定（如透过发动机或电机提供扭矩）；“系统特征”则定义系统透过硬件与软件协力工作能做到的事（如车辆的自动纵向控制）；“系统服务”则是彼此独立能轻易解耦的完整行为，通常是叠加在“系统功能”与“系统特征”之上，可增可减并且增减过程不会互相影响的高级行为（彼此低耦合），称之为“服务”。
SOA的奥妙之处，在于把汽车平台当作一个系统，并由这个系统上所具备的根本硬件能力为“系统功能”基础，来叠出一个又一个不同的增值服务。笔者开章就提到，SOA的赋能若是在10年前出现或许没有多大意义的主要原因：就是今日我们若把汽车作为一个系统，这个系统已经具备了充分的视觉功能（摄像头）；触觉功能（Lidar/ Radar点云）；感觉功能（温度与雨滴传感器）；听觉功能（麦克风）；思考功能（算力平台）；沟通功能（V2X，音响；喇叭）；移动功能（纵向/横向）……它能够实现的事情实在比手机系统多太多。
如果我们拿打篮球这件事来类比：上帝给我们创造手并不是为了让我们打篮球，但我们在具备“手”这种基本功能后，又发现结合“脚”的基本功能，我们便能开始延伸学习“打篮球”这件事。
当然打蓝球这件事能够真正实现，还依赖于我们定义了篮球的规格；篮球框的规格；篮球场的规格以及游戏规则。这在汽车领域的SOA也是相同的，未来若是汽车世界衍生出很牛的服务，除了服务调度到更多的车辆本质功能，也很大概率会依赖于对外在环境的适当定义来妥善发挥这个“增值服务”的价值。
至此，笔者想稍微总结下：传统汽车或复杂系统的设计，主要是自上至下，但今日软件定义汽车及SOA时代的来临，意味着系统设计也可以自下而上！关键在于这个设计能不能让系统实现特定的目标。
在系统设计理论的下一篇文章，也是最后一篇文章中，笔者想花些时间谈谈系统设计的方法与实践，总结一下个人过去十多年摸遍数十个不同的系统后累积的心得，尤其我们必须澄清“系统设计”与“系统整合”这两件事截然不同的价值，目前国内汽车业的车厂虽多，但多半在做的事情是系统整合而非系统设计，希望这三部曲的文章最后一篇，能作为刺激我们汽车业更勇于摸索实践创新系统应用的基础。
