2023年11月3日，2023中国汽车软件大会在上海嘉定举办。本届大会以“聚软件之力，创数智未来”为主题，由中国汽车工业协会主办，中国汽车工业协会下属单位中德智能网联汽车推广应用中心、上海智能汽车软件园共同承办，中国汽车工业协会软件分会、智能网联汽车分会和中国汽车工程学会汽车基础软件分会协办。紧扣新时代汽车产业高质量发展和汽车软件发展要求，本次会议设置了“1场大会论坛+4个主题论坛”，旨在打造汽车软件领域开放、高端、权威的交流与沟通平台。其中，在下午举办的“共启汽车工业软件新征程”主题论坛上，倍睿软件（上海）有限公司功能安全产品总监戴兵发表精彩演讲。以下内容为现场演讲实录：

　　今天下午听了很多前辈们的演讲，感触很深。大家应该都是国产软件的产商，整个下午只有我是国外的厂商。这边我也不过多讲解我们公司工具提供的能力，根据大家讲解的内容谈谈国外对于软件开发的一些理念，刚才听到了上一位演讲易总的最后一页PPT，讲到对于他们自动化模型设计，最后他们自己有建工厂验证。这种思路我是非常认可这样的理念，包括其他的国产化软件，虽然大家会说我有实现一个什么样的功能，但是你真的有在整个研发过程中验证过你的软件吗？你做了一个软件，回头就甩给你的客户，让你的客户帮你做验证，这是一种极不负责任的做法，这种在很多的国外厂商看来是很不可理喻的。
　　今天我大概从两个方面给大家做一些分享，基于我们的产品谈谈我对于软件应该要做一些自我证明的过程，希望给各位国产化的软件产商，在软件研发过程中带来一些新的思路。
　　汽车以前是硬件居多，随着新四化的发展，汽车软件这块变得特别多，特别是变成电车之后，当然也会带来一些用户的反馈。比如说我们在重庆，你坐出租车时，出租车司机直接跟你讲这个车卖给我们跑出租，除了四个轮子可以转，其他都不是，有各种各样的问题。
　　在这样的过程中我们可以看到，变成电车之后我们软件的比重就会非常多，除了以前的一些发动机的控制很多可能就会变成一些电机控制。整个软件的研发过程也会变得越来越重要。在公司里比如我们要去研发一些产品，你要出口欧洲，必须要满足一些标准。这样的标准是对你自身软件的自证过程。汽车软件衍生自ISO61508的标准，再往下是ISO26262道路汽车安全的标准，在这样的标准里面，我们需要去细化定义我们关注什么样的东西。
　　这里的标准前面有非常多的章节，这里跳过，可能涉及硬件产品，包括后面运维部分，我们着重讲解软件产品验证过程。
　　在整个软件研发的过程中，首先我们要对软件有一个整体的研发和设计的总则和思路，这样的总则和思路很多人可能认为，软件的设计可能是一些模块的划分或其他的，其实这个是远远不止，软件模块怎么划分、拆分你的需求，这只是其中很小的方面。更多的是你需要遵循的原则，这些原则是看不见的东西。通常我们需要用这些看不见的东西指导我们能看见的一些事，我们用可以看见的东西反过来验证我们看不见的指导原则。
　　在这些标准里，和软件整个研发过程相关的涉及到第5、8、9、10、11这些章节，每个章节会做一些细化，你应该在软件过程中去做什么，你只有作到了并且证明你做到了，用户才会对你的软件有信心。
　　对于我们ISO26262软件开发过程中，这页PPT大家可以看一下，这是我们C/C++test可以提供的功能，后面的PPT中我会逐步自证为什么我们公司研发的产品可以帮助大家满足ISO26262。下面是一些明细。在我们软件V字研发过程中，如果我们有做软件功能安全的概念，基于这样的概念，可以衍生一些软件的需求，最终做软件结构设计、编码。

　　基于软件的条目、设计之后，我们怎么样验证我们在这个设计过程中确实有完成验证的过程，右边的部分就是在整个标准里提出来的。这个设计的概念可能是流程化的，那么它可能提到一个概念，我们尽可能在目标板上进行测试或在仿真件上进行测试，最终你有没有落地它，你是怎么落地的，这时候你需要提供右侧的证据证明你确实做过并且验证过这样的结构设计。

　　我们就会在整个工具里根据ISO26262标准拆分所有的条目，看到每一个章节、每一个条目或每一句话，在这句话下我们产品会拆分出什么样的功能应对并满足这样的标准，并且会产出相应的报告或是数据来呈现，我们整个软件的研发过程中我们确实有去完成这样的事情，一个不少的完成这样的事。
　　那么下面是一些相关的明细，比如标准里我们按第5.4.6的章节讲到。首先我们要实现一个低复杂度的实现。什么是一个软件的低复杂度的实施。这个地方如果做一个工具就要进行细分，当然在标准里有些条目有做细分的，我们需要把这些内容落实到一个具体的可以执行的一个层面上来做，我设计一个软件的话首先如果它要是一个低复杂度的实现，那么我觉得或我们工具在设计之初认为复杂度是好的衡量，它是否是低复杂度的这样一个实施，基础复杂度或偏专业性的代码可维护性的度量，还有其他的一些度量指标，比如说很多人可能会经常来问我们说这个嵌入式环境我们在运行过程中堆栈爆炸了，整个嵌入式的软件crush了，为什么产生这样的现象？引发原因有很多。当然一方面可能来自于不是一个低复杂度的实现。比如代码调用路径很深，调用参数非常多，而且动态不可控。使用低复杂度的实现显然可以显著降低这点。这些内容我们就会把比如说代码参数个数，参数可占的字节数，作为你的度量指标一种，你在工具里实现对这些内容的一个检查，以此证明对低复杂度实施有相当多的检测手段，逐一检测并罗列我确实有检测这样的项而且没违反。
　　通过这样的一个方式我们来证明它，我们在整个的软件研发是ok的。只有你经过充分的自证过程，你的用户才会对你的工具有足够的使用的信心。当然下面有非常多的条目，我这里大概阐述一下。
　　我们在整个ISO26262里分为几个大点。第一个我们称之为静态分析。静态分析是指我们在不运行软件前提下仅从代码特征的方向对代码内容做出分析。标准里罗列了这些点，可防御性，还有要用可靠的设计原则或用一些语言的子集或使用一些命名的约定，还有类型转换等等这样的类型。所有这些都是属于静态标准里的。我们全部罗列成为静态的某一种具体的可实现的一种规则。
　　工具的话通过你去选择一些规则对你代码进行判断，通过这样的方式可以证明你的软件在设计过程中，如果采用了这样的设计原则，最终你是可以落地的，你确实有做到这样，而且可以通过工具软件的检测。
　　第二大点就是动态测试了。动态测试主要是以单元测试为主，当然单元测试很多人会有一些歧异，实际上单元可大可小，纯软件开发工程师认为单元就是一个函数，在整个标准里这个单元可以是一个函数，可以是一个类，可以是你项目下面的一个模块，甚至是你整个ECU上可执行的一个程序。
　　这样的单元要进行粒度的拆分，拆到你足够可以支撑使用下面设计、可落地的原则为止，再进行正式测试、并且落地。实际开发过程中可能是反向的，我们认为一个函数肯定可以测试的，一个函数再往上，单个文件是不是可以测试，文件往上小的文件夹、小的模块是不是可以测试，通过这样的方式逐步反推，一直往上，可以推导到整个软件的集成测试过程中，最终完成模块或一个系统的子系统的测试。
　　我们可以看到第9.4.2章节这里，如果我有详设的话，基于详设对于函数输入输出，我会有自己的校验，上升到模块会有接口的相互间的调用关系，子系统外部有输入，能不能通过控制外围子系统的输入进行验证，我们可以在C/C++test工具中支持你的多种模式，从函数级别到你类级别再到整个的模块级别，都可能帮你满足。
　　ISO26262软件部分中第三个内容主要讲需求，包括一些关联关系，最终是你这个动态测试过程中你应该要满足的一些指标，所谓的这些指标就是说你做了测试，但你做的够不够全面、有没有达到一个百分比，这里有几个地方需要你达到百分比。
　　首先你有一千条需求，一千条需求是不是都做过测试，需要有一个地方呈现你做的内容的确满足你的需求。第二个动态测试每一行代码是不是都有做过这样的测试，每一个条件是不是都有做过测试。函数和函数之间是有调用分支的是不是所有的分支都有能够满足这样的测试。这些内容都会通过工具的细化，使用工具的功能，并且在工具里完成分支节点的计算，最终的话会将这样的一些报告输出在报告系统里进行证据的证明。
　　这边的话我就讲到这里，也非常感谢大家。这是我们合作过的一部分客户，在这里给大家展示一下，非常感谢大家！
　　（注：本文根据现场速记整理，未经演讲嘉宾审阅）