汽车软件工程的思考（1）：设计、实现和团队交流

汽车产品从一开始完全由机械部件构成，发展到现今，软件渗透到车的各个部分，已经历好几十个年头。从车身控制，到底盘，以至发动机控制，处处都有软件的参与。软件唱主角的时代已来临。而这貌似水到渠成的趋势，其实是一种必然，对于这种必然性的解释，就是软件具备一种核心能力，它可以帮助人们解决复杂而抽象的问题。软件是抽象的，它看不见摸不着，而正是这种特点，给予事物以额外的意义。软件类似于人的灵魂，赋予每个人有趣，坚毅，善良等特质。车也是如此，当前汽车的软件世界类似包子铺的功能，以满足基本需要为主。而未来汽车的软件世界却是“超级文和友”，是个层次鲜明，有条不紊，丰富多彩的空间，满足人们更美好的愿景。

　　为了实现这美好的愿景，软件定义汽车的话题被不断地展开。朋友圈经常能看到谈论汽车相关软件技术的文章。诚然，软件技术关系到最终方案落地实现，不可否认其重要性。然而，容易被大家忽视的是，首先汽车是需要被设计出来的。不单单是设计汽车的外形，它的功能，还要设计它的构成，运作方式，以及其他一切需要并可以被设计的细节。而这设计的细节最终应能准确地以软件的方式去实现。而这设计的过程，亦是定义的过程，有了这个前提，才能说我们开始了践行软件定义汽车。这个过程必然不轻松，对于当代汽车工程师来说充满挑战。万丈高楼平地起，我们要做的是为未来铺下坚实的基石，对于这么有意义的事，怎能不好好思考。

面临的挑战

　　关于汽车功能设计，也许有人会觉得没有必要，这些功能明明白白就摆在那了，但这些想法是错误的。首先，当前汽车所具备的功能也不是从汽车诞生那一刻就有了的，只不过前辈工程师们已经帮我们设计好了而已。其次，企业不从自身出发去创新，产品将永远落后而失去成为领头企业的机会。创新是困难的，守株待兔的方式去等待灵感乍现显然不现实。创新的基础是对现有知识的充分理解，要求对现有知识的储备机制具备完善的自身解释能力，并且有很强的维护扩展能力，能够形成稳固的基础能力和框架，基于此再扩展出强大的新能力和特性。

    　设计、实现和团队交流面临的诸多挑战：

１.　怎样应对面向服务的整车功能架构设计

　　我们知道，最新AUTOSAR标准已经将面向服务化的设计融入到了它的方法论中，对软件实现服务的方式也进行了详细的定义。AUTOSAR对最终的软件产品提供了标准化的服务设计和实现方式，当然服务架构的实现方式可以多种多样，AUTOSAR是其中一种可选的方式。而对于现有汽车领域知识进行提炼抽象，最终形成服务设计的过程，依旧需要ＯＥＭ从自身出发，探索出行之有效的方法。

　在基于信号的系统及软件架构设计过程中，方法论往往被忽视。其原因也许是基于信号的功能设计已经有固有思路可以去遵循。当工程师收到新功能需求要求后，分析出该功能的执行过程，整理出需要的输入和输出信号。然后从现有的网络信号集，或者ＩＯ输入输出信号中找到可以复用的。假如没有可以直接复用的，则需要增加或者转发所需的信号，相应ＥＣＵ则需要修改。这也是被大家所诟病的。以现在的眼光来看，这种信号层面堆砌功能的设计方式已经落后了。这也是面向服务设计理念提出来的缘由。

　　基于服务的架构，不再是单一层面信号的堆砌。对各层能力进行抽象，形成立体的，递进式的抽象层次关系，使最上层的逻辑不必关心最底下的能力的实施细节。以军事指挥系统打个比方，以班为编制的最小作战系统（９－１２人），班长可以直接指挥每个士兵，命定的传达迅速高效准确。每个班可以执行简单任务，但简单的堆砌作战小组是无法执行大规模战役的。随着军队人数的扩充，编制有排级，连级，以至更高级别的作战单位。这时各层级之间传达的是战术指令，而非每个士兵要做什么，而每个层级之间产生的

战术指令是可扩充，可拓展的，可以引领出各种新战术。

　　把军队中各层级之间的战术指令认为是一种能力的抽象，那汽车功能设计也要做这类能力的抽象。能力抽象与提取，也可以认为是服务的定义，这是一项复杂的工作，需体现出一定的原则。比如，（１）单一职责原则，即服务只应关注整个系统功能中单独、有界限的一部分。（２）服务自治原则，即每个服务应当具备独立的业务能力、依赖与运行环境。

　　以上的原则比较难表达，引用以下文章帮助理解。

　　首先写下一个句子，

　　然后将它分成小段，

　　再将它们打乱并重新排序。

　　仿佛是巧合一样，

　　短语的顺序对意思完全没有影响。

　　——Lewis Carroll, “Poeta Fit,Non Nascitur”

　对于ＯＥＭ设计团队来说，当前面向服务的设计过程是最先直面的挑战，建立起一套完善高效的服务层框架，对后续应用层的搭建将起到至关重要的作用。

２.　系统设计如何有效地传达给到程序员

　　相信很多软件从业者都思考过这个问题，本人在和系统工程师不断的磨合过程中，也有过思考并尝试着实践新的方法。

　（１）偏向自然语言的设计表达方式。优点是设计人员无需学习专门的技巧，入门门槛低，设计贴近终端用户的需求。缺点显然易见，即使再详细的功能描述，始终系统设计表达方式和软件代码实现相差太远，两者无法形成有效的正反馈机制，完成设计和编码的迭代过程。

　（２）伪代码的形式。优点是贴合程序员的思维方式，表达严谨不容易产生歧义。但依然有较大的缺点，过度使用的结果是系统设计层面功能的退化，缺乏整体结构推导的过程。相当于直接以写代码的思维方式设计框架，限制了程序员发挥的空间，最终的代码实现将是死板的。

　（３）状态迁移图与模型化的表达方式。该方式容易理解设计的过程与用意。最大的挑战是能不能形成一种统一建模风格，并且具有传承性。如果千人千面，则依然起不到很好的效果。另外考验设计者对业务抽象的能力，模型是否能充分反映业务的深层次关系对于方法的成功至关重要。还需要防止的是过分细节的模型化视图，模型不应当成为程序的另一种视图，那样，模型的真正含义就丢失了。

3. 统一的描述语言来解决沟通的难题

　　要想创建一种灵活的、蕴含丰富知识的设计，需要一种通用的、共享的团队语言，以及对语言不断的试验。

　　首先假设这样一种情况：软件开发人员掌握的是软件技能，对车辆领域知识甚少。车辆功能专家掌握的是车辆知识，但对软件领域的知识甚少。这也是现实的情况，很难要求工程师对所有技能知识都是熟练掌握的。所以会存在一个复合人员的团队构成，比如系统、软件、测试工程师这样的组合。

　　我们常常有这样的经验体验，由于语言上存在鸿沟，功能负责人只能模糊地描述他们想要的东西。软件开发人员虽然努力去理解功能，但也只能形成模糊的认识。虽然有些已开发过相似功能的资深队员可以帮助新的队员理解各种细节，但他们会变成信息流的瓶颈，有时候解释的也不准确。所以，单单依靠有经验的人是不能解决这个问题的。

　　功能设计工程师有自己习惯使用语言，软件程序员又有他们偏好的语言。现实的情况是团队中的任何一方的语言都不能成为公共语言，因为它们无法满足所有的需求。日常讨论所使用的术语与软件代码中使用的术语不一致。甚至同一个人在讲话和写东西时使用的语言也不一致，这导致的后果是，对功能的深刻表述在转化为代码或记录到文档中后丢失了很多关键信息，自然导致无法开发出可靠的软件。

　解决的方案是所有开发人员应该使用基于模型的语言来描述系统中的元素、任务和功能。这个模型应该为开发人员（包含系统，软件，测试人员）提供一种用于日常相互交流的语言，来讨论需求、开发代码。语言使用得越普遍，团队之间对功能的理解就越一致。

４. 形成有效的正反馈机制，加速产品成熟

　　前面提到当前车企面临着新架构，新功能的开发。新，意味着是无章可循的，知识体系需要被创造和完善。车企即使有专门的团队去设计与开发，也总有他们想不到和设计不合理的地方。这就需要所有工程师们参与到设计及实现的每一个环节中。

　　要实现这种正反馈效应，共享模型是关键，是团队成员之间交流的媒介。另外敏捷方法也能很好地支持这种机制，包括敏捷团队的构成方式，还有产品迭代开发与运作的理念。

　　项目开发之初，团队仅有对未来功能的设想，并没有模型可供使用。当开发人员在一起仔细讨论这些新想法时，探索共享模型的过程就开始了。最初的模型可能很笨拙且不完整，但会逐渐精化。当运用这些共享模型进行互相讨论时，队员们很快就会发现模型中哪些地方不符合他们的需要，甚至是错误的。另一方面，模型语言的精确性也会促使设计者发现他们想法中的矛盾和含糊之处。模型也是维系敏捷会议，并推动产品向深层次讨论的重要因素。基于模型的讨论，每个人都可以集中注意力。所有人就对象关系会达成一致的认识，更重要的是，他们将使用相同的对象名称。如此，讨论会更加高效。当有人尝试不同的想法时，也随之展现在模型的变化上。

　随着项目的推进，功能设计者可以清楚的看到他们的设计融合到模型中，然后反映到软件上。他们也可以从模型原型得到具体的反馈，从而印证自己的想法。

本篇小结

本篇就汽车领域设计、实现和团队交流面临的挑战列举了一些方面，我们面临的挑战和实际困难也许远不止这些。在汽车行业进入架构和软件高速发展的大背景下，总结当前储备的知识体系，思考未来能带给我们更高生产力的新模式，是相当有意义的。希望有机会可以带来更多的分享。

文章转载自公众号：汽车电子与软件