LabVIEW技能加持，完美实现，汽车行业复杂测试

师子一号第一次接触LabVIEW，是在大三，当时觉得它好复杂，各种操作真反人类，好讨厌。

公司卖给客户的电池系统，在充电的时候出问题了，有点小故障，需要出差去排查一下问题。

但是客户的通信协议有点特殊，公司现有的上位机解析不了，没法定位问题。

这个时候，你作为系统负责人，如果懂得如何解析通讯矩阵，懂得如何开发一些简洁直观的上位机，你就更能把这个质量问题搞定！

电池系统的CAN通讯，往往是大量的id，用来表达N个电池单体的状态，有的甚至是multiplex类型的复用报文。

然后你凭借着这个贡献，获得了当年的优秀标兵。

技多不压身，这个时代需要的是复合型人才，这样的人才在当代社会中更能抵御职场动荡。

项目接口人丢给了你一份blf文件，说这是从实车上录制下来的报文，让你去核对一下它和设计文档的区别，看看这个车上的各个网段中，哪些控制器多发了、少发了、错发了……

这绝对是一个让人抓狂的事情，在汽车电子测试领域，这是一个巨大痛点。

从CAN总线诞生近30年来，特别是最近10年来汽车电子电控飞速发展，车上的ID越来越多，管控越难越难，从来没有人能高质量、低成本地完成这个事情，行业最优秀的供应商，也鲜有搞定这个事情，几乎无解！

传统的做法是怎么样的呢？

• 第一步：在CANoe中打开这个blf，然后run一下，统计出各个网段的ID实际属性，比如周期、DLC、ID等等。

• 第二步，打开通讯矩阵文件，一般是excel。然后肉眼观察，CANoe里面的ID清单，和通讯矩阵中定义的是否一样。这一步非常麻烦，非常难受~

这个工作实在是太不好做，以至于相当多的工程师，就只查看最近一次设计变更有没有实现，就算完事了。比如某个控制器新增了一个id，就只查看这个id有没有发出来，就算完事了。

窃以为，这样做有一丢丢不负责任。。。

优秀的你，会怎么做呢？

你可以用LabVIEW，花了7天时间，自己开发了一个工具，读取dbc和blf文件。提取其中的信息，就能实现了二者的双向核对，并且自动出具格式精美的测试报告。

完美识别各个网段的多发、漏发、错发，2分钟即可自动分析完成。

不查不知道，一查吓一跳，借助这个用LabVIEW开发的工具，你甚至会发现了好几个很早就存在了的问题。

有好几个网段、ID都和设计状态有出入……

然后由于这项贡献，你被大领导重重地表扬了一把，心里美滋滋的。

从此之后，这个行业痛点被彻底搞定，公司内部这个业务方向归你占有。

场景2

公司的NM网络管理总体采用的是osek，统一要求各个控制器的供应商按照公司发布的osek【企标】网络管理规范予以实现。

但是，这个规范有一些自定义的部分，供应商可能会理解错、做错，而且部分供应商是没有osek协议栈开发经验的，也可能做错。

这就要求你们公司具有osek网络管理功能自动化测试核查的能力，保证对产品质量的控制，确保心中有数。

向供应商询价，购买这样一套工具，对方报价60万，开发周期9个月，且后续如果修改，另行收取开发费。

你们公司前年买了一套高大上的HIL设备，供应商当时说，改一下工程配置、模型、修改一下线束，啥都能测，BMS、VCU、EMS都能做。

但是，改来改去几次之后，设备出了点小问题，质保期也过了，没人管了。

领导想把仓库的一堆第三方板卡用起来，用CustomDevice来实现，做好多套紧凑型HIL，放办公桌上用。

OK，你的机会又来了，因为你会开发CustomDevice，然后你又一次成为了“突出贡献员工”。

那一排紧凑型HIL，整齐划一地站着，跟示威似的，就是你的成绩，你又牛逼了一把。

师子一号对汽车电子测试技术有深入的研究，对各种开发语言均有应用经验，比如python、C#、java、Matlab、LabVIEW，但是最终还是发现，对汽车行业的测试分析工作而言，还是LabVIEW最好用、效率最高。