2025.01.17.3个月BMS HIL Engineer的一点感受
Nathan 转战 HV Battery BMS HIL Test Engineer 已经有3个月了。
从一个电池包开发系统工程师,转变为电池管理系统软件测试工程师。
这中间的变化还是挺大的,有些体会,记录一下:
转岗前后的工作内容大不相同
传统的电池包系统工程师的工作,更多的是:
- 从整车定义的需求出发,
- 从电池包在整车的空间布局,
- 到需求的理解,
- 再到分解给下级零部件,
- 以及往后的整包设计开发阶段的相互协调,
- 最终有了设计阶段的数据冻结;
- 样件生产与整包第一次装配以及测试;
- 处理装配和测试过程中遇到的各种问题;
- 将问题的解决方案更新到设计中;
- 第二次装配/测试,再到电池装车,跟进装车问题;
- 最终支持电池包量产前的准备;
- 和上市后的质量问题;
HIL 软件测试工程师,工作内容是单纯的软件测试
- 和软件开发团队沟通,明确需求
- 设计测试用例
- 开发测试环境
- 测试报告分析,支持软件开发团队解决问题
可以看到,HIL测试工作相对单纯,不需要大量的跨部门沟通协作,主要是和软件开发沟通,我称之为相对封闭,与外界接触的比较少。
而之前的电池包系统工程师的工作就需要大量的沟通,当然,沟通的前提是需要对技术细节的理解,在理解的基础上进行沟通,才相对称职。
目前对BMS HIL的浅显认识
在软件的世界里,逻辑很重要,软件即是对逻辑的实现。
其实现实世界里,逻辑无处不在,并不是软件的专属。
HIL测试用例也是逻辑,是对测试需求的正向/反向验证。
软件世界里更需要清晰的表达,准确表达能够提高效率。
HIL 用到的 python 知识没有想象中的那么多,不过懂一点
python的确会对HIL工作有所帮助。HIL的自动化测试脚本要写的很清楚,方便同事理解,也是方便自己在长时间以后可以理解。做到这一点并不容易(比如下面这张图,严格意义上讲,备注的不够清晰明了,比如不知道第二步是在干嘛)。
HIL 的自动化测试,和 微软
Microsoft 365里面的Power AutomateFlow 工作流 很像,都是一步步的向前走,完成第一步,再完成第二步、第三步,现实世界不也如此?题外话,我很喜欢 Power Automate,它帮我完成了不少生活中的自动化工作。可以说 Microsoft 365套件中,Power Automate绝不是锦上添花,它和
OneDrive和Microsoft Graph API, 让 Microsoft 365 从 单纯的Word/Excel/PPT 变成了更多。
对工作的一点想法
- 在考虑是否有必要利用Python优化一下自动化测试报告,只提取出其中的测试未通过相关的信息,方便分析报告。
- 在考虑是否有必要对自动化测试脚本中
打印输出的部分做必要的更新,添加未通过时的相关原因描述,以方便分析报告。 - 在有限的时间里学习更多的知识,比如
Matlab,Simulink。
希望来年,可以在工作上更进一步,对BMS软件有更多更深入的理解,也对动力电池整体有一个更全面的认识。