拆解一下汽车电子软件开发工具链

已剪辑自: https://mp.weixin.qq.com/s/hQsc_szBWJvR_ouTwHaw3g

都在讲数字化，数字化的第一层是IT工具，工具打通就是工具链。在数字化的进程中，我们现在能够比较好落地及落得比较好的就是工具链，工具链也几乎是能把敏捷与标准化平衡好的最佳方式。

今天，我们来聊聊汽车电子软件行业目前使用的工具链，由于不同公司的工具种类纷繁复杂、不同的人使用经验与习惯千奇百怪、不同开发理念对工具的特有需求五花八门（如敏捷、DevOps、仿真在环等）、不同产品类型与不同复杂度的软件及不同角色对于工具的需求也各有不同，而且私以为汽车软件工程基本框架和方法论并未有颠覆性变化，所以本文尝试整理一些常用的工具，但不追求全面不遗漏，也不会涉及太多使用方法和操作技巧的内容，而更多的是结合当前V模型的业务惯例与一些日常工作体悟进行的梳理。

开始前先说点别的。“做正确的事”和“正确地做事“这两个概念，大家应该是耳熟能详了，据说是德鲁克在一本书上讲的，没确认过，但也不要紧，我们也就是拿过来作为参考。

认真完成本文标题的目标和把工具链使用得炉火纯青，自然属于正确地做事，但这是在“做正确的事“吗？

其实，发出这个疑问，除了德鲁克的启发外，还有一个原因，我对工具的态度的转变，也正好结合对自己想法变化原因的反思，来探讨工具的意义。

早些年的一段时间，我对工具的态度大约是属于嗤之以鼻，总觉得用工具的人缺少思考和业务能力，纯粹是熟练，工具本身难以构成突出的竞争力，工具人甚至被认为是能力差的代名词，特别是对于早期制造业中较多接触到的CAD、CAE、SAP、ERP、PLM及一些实验排期或库存管理的系统等。

随着在汽车电子软件领域经验的积累和对数字化及敏捷开发等的理解的深入，越来越深刻地体会到充分使用工具的必要性。多说一句，制造业多会叫软件或系统，不习惯叫工具，从称呼上其实也能体会到一点定位上的差异。

细究原因，产品与行业的需求是一部分原因，另一部分原因也来源于自己职场或社会经验的叠加，工具类似于一种资源、一种手段、一个杠杆，个人加徒手能够完成的工作是极其有限的，借力才能大力。没有工具的话，我们所依托的其实只剩下“语言“，思考需要基于语言，沟通更离不开语言，而语言是局限的。

举个最简单的例子，当你用图表这种基础工具去描述一件事物时，你做的不是简单的语言同态映射，而是不同逻辑和模式下的表达与展示，看这个图表和对应的描述文字时，你获取的信息、感受、思考与灵感均是完全不同的，这就是”图表“这个工具能给你带来的额外价值。

这个道理并非新颖，但在汽车电子软件这个领域，对于多数人来说，并未迈入工具及工具链的门槛，当别人都还习惯于excel码字、打电话和开会时，你用到这个杠杆，可能会帮你更容易撬起来一些你想要的东西。

**
**

按照汽车软件的来龙去脉，基本会有这7个环节：需求、架构、开发、集成、验证、项目管理、配置管理，对应的有相应的工具。

当然，不是每一个环节都是一个单独的工具，很多工具开发者都希望尽可能涵盖更广，所以，理论上，一个工具可以支持很多环节，甚至是全生命周期的。但是，基于惯例或者各自优势，每一个环节又会用到比较流行的工具或某个模块，一个工具也会交叉使用在不同环节上。

下面做一些整理，应该基本可以反映出当下汽车行业惯用的一些工具。

**需求：**Doors、DNG、JAMA、Polarion、TRM、Clear Quest、Reqtify……

**架构：**OpenAmeos、Rhapsody、Systemweaver、PREEvision、Pure:Variant、Visio、EA、Simulink、AUTOSAR Blockset……

**开发：**Eclipse、VS Code、Jenkins、Wind River、Perl、Green Hills、Vector、Source Insight……

**集成：**Jekins、RTC、Harness、MAKEFILE……

**验证：**Coverity、Polyspace、Tessy、QAC、Gerrit、Parasoft、VectorCast、dSpace、CANOE、CarMaker、Reactis、RQM、ECU-Test、JIRA、Gtest、PC-lint、Findbugs、Junit……

**项目管理：**JIRA、Polarion、RTC、Clear Quest、Git、Asana、飞书、Project、DTS、RDM、Redmine、禅道、PTC Integrity……

**配置管理：**RTC、SVN、Sharepoint、MS Teams、MKS、Gitlab、Confluence、PlasticSCM、ClearCase、Synergy、Preforce……

我一直比较排斥造词、造概念等故弄玄虚和简单问题复杂化的行为，说起来天花乱坠且清新脱俗，做起来还是老一套。

对于工具链的“链“，我们也不要把它想得多么高深。

简单理解，”链“就是建立链接和数据同步。再扩展一点，就是建立不同但相关数据的链接和相同但不同区域数据的同步，前者侧重静态关系，后者侧重动态流转。

当然，链条里不能忽略人，但人脑子里没有天线，无法直接建立连接和传输数据，把人加进链条更多是把与人交互密切的载体加入链条，比如，手机和邮箱。

而且，人在里面的作用越小越好，人作用越小，说明自动化和智能化的程度越高。

ASPICE要求我们做追溯，追溯就是典型的建立不同但相关数据的链接，用文字描述、excel贴链接、变更履历里加编号，甚至测试发微信给需求，这都是建立链接，方式有多种多样，只不过都上系统后，工具里直接建立链接会有更多的好处，比如，稳固、清晰、透明、历史追溯性好等。

除了工程里的追溯，不同系统间可以自由跳转访问也是一种很实用的链接。

数据同步和我之前多次提到的数据同源有一定的关系，数据同源是提升透明度、效率、准确性的良好手段，良好的数据同步又是实现数据同源的支撑。

无论是面对频繁变化的项目计划、不断迭代的软件，还是处理成千上万的Bug，或者完成整合数据的配置管理，或者进行不同区域和组织间文件的传递。通过工具的打通，让数据流转起来，让数据自动同步，这都是工具“链“的重要需求。

此外，建立连接和传输数据不一定就是简单的原始连接和源数据传递，可能更需要特殊的匹配、统计、计算等处理工作，比如，需求和测试系统经过比对识别符来完成链接，并在此基础上自动计算出覆盖率。

基于多种客观原因和主观考量，“链“的建立并不容易，数据孤岛和部门墙依然风行。然而，这种现实的弊端正是工具链存在的价值及大家对它的期许。

我们多数不是专门的工具链公司从业者或者说本文多数受众不是，**我们不需要深入到工具开发逻辑层面，更多是在工具的应用和功能挖掘组合上。**其实，当前流行的工具内嵌了很多强大的功能，实际被挖掘使用的部分却又是非常少的。

首先呢，我认为是尽可能用出花样来，要全面，要结构化，要美观，要自动化，不要去依赖于传统的excel、ppt，尽管Office非常强大，但非常基础和普遍，经典的不等于未来的。

玩工具链也并非目的，而是手段，是显示出你的独特性的手段。业务能力有高低，经验积累有厚薄，你使用工具展示、汇报、分析的水平也是一种资源。在全面数字化和智能化到来之前，工具化是一个必经之路。

其次，或许没必要系统学习，有那么多工作在等着，我们无法投入太多精力在工具上，但应该时刻思考并寻找工具的支持，如何将自己的一些工作数字化、工具化。

未必需要自己亲力亲为，大一点的公司都会有工具组，要充分利用好他们。在不断的过程中，学会用工具加速自己的工作，理解工具的运行逻辑，将自己更多的时间投放在创造性的思考上。

既然智能化时代终将来临，不妨主动迈过去。

写到这里，我同时还在反思自己行文的基准——工具是否有那么重要？我们惯常讲的一句话是“这只是一个工具”。言下之意是，这没那么重要。而这不由得让我想起，也有很多人说过“语言只是工具”，可在我多年外企的经历中，深知一口流利的英语给人职业发展带来的助力是多么大。

长期以来，我们很多人都被不会借力、借工具、借资源所误。

推荐阅读

国内主机整车EEA架构汇总

谈谈整车OTA系统的理解

五千字说清汽车基础软件及国产现状

带不带功能安全(IS26262)的区别，功能安全要做啥？

谈谈simulink自动代码生成

浅谈电机控制器及其功能

谈谈Bootloader自更新

电子电气架构设计需要考虑哪些方面？

汽车E/E架构的网络安全分析

深度解读汽车域控制器

自动驾驶域控制器信息梳理