[发明专利]汽车电子软件开发过程的问题定位方法

说明书

技术领域

本发明涉及一种汽车电子软件开发过程的问题定位方法。

背景技术

在各种工业及汽车行业都用到了诊断，但诊断的对象基本是外围器件，前提还必须是此控制器软件本身是正常的，目的是为售后做准备。对控制器的软件本身是否正常却没有办法确定。

随着国产品牌汽车开发从低端产品向中高端挺进，车载控制器越来越多，其控制内容也越来越多，相应的控制逻辑大大复杂，系统间的交互也会频繁起来，使得开发难度在加大。在产品开发过程中常常发现，某一个车载控制器基本功能早就能满足要求，各种试验也都已通过，但还是存在这样那样的小问题。有些问题可以重现，容易分析解决；另外一些问题却无法重现，当事人也无法仔细描述当时的情形，或者无法解释怎么回事，给分析改进带来重大困然，造成产品开发进度一拖再拖。究其缘由，还是由于其设计软件存在bug，因此可以看出，国产汽车电子开发的主要瓶颈还是在于软件设计。因为结构、硬件方面的问题经过几轮试验和改进后都能满足要求，只要肯下功夫、能给经费、努力去做就行；而软件方面的问题不是肯努力有付出就能解决问题的。虽然现在有许多的软件开发工具，但这些工具主要起着降低人的低级错误概率、减少一些重复动作的作用，具体的控制器功能软件设计思想还是要靠人去做，这些设计思想、策略在转化为软件代码时就可能出现小问题，最终体现在产品功能上。

产品在开发过程中出现问题并不可怕，可怕的是不知道出现了什么问题，要如何分析解决问题。出现这样的问题将给产品及项目管理带来不可控的风险，也许到了量产阶段都未能解决。据了解，软件开发行业时间进度存在5/95现象，即开发周期5%的时间可以完成95%的软件代码工作，而剩下的5%软件代码工作需要95%的时间去完成。可以看出软件开发的大部分时间都是在分析、查找、解决问题，如果能提高问题的定位、查找、分析能力，将大为缩短产品软件开发时间和产品的开发周期。

发明内容

本发明目的是针对现有技术存在的缺陷提供一种

本发明为实现上述目的，采用如下技术方案：

本发明汽车电子软件开发过程的问题定位方法包括如下步骤：

S101、确定要记录的状态信息

所述状态信息包括控制器的输入状态、输出状态以及控制器要用到的内部状态信息；

S102、状态信息映射成状态表

把步骤S101中所述的具有定性的状态信息映射成一个具有唯一识别性的列表，所述列表存储的是列表中映射后的数值；

S103、增加状态变化记录模块

当某一参数（具体为什么参数？）任一被映射的状态发生变化时，所述状态变化记录模块把此参数状态映射后的数值给存储到EEPROM中去，且此状态改变导致的内部状态和输出状态改变也被记录存储，所有的这些状态变化按照发生的时间先后顺序记录存储；

S104、增加记录上传通讯机制

所述控制器设置有通讯端口，通过此通讯端口对记录数据进行读写、删除操作；

S105、建立查询机制

通过查询机制与控制器通讯端口对应的连接，来对控制器中存储的状态变化序列进行读写、删除操作，并显示状态变化序列；

S106、查询分析原因

当遇到有疑问的问题时，通过查询机制得到状态变化序列，将此序列与功能规范比较，看是否符合功能规范要求，如果不符合要求，将不符合的地方对照相应的代码进行定位。

优选地，控制器的输入状态包括开关的开状态和关状态、点火钥匙的位置状态、电源电压、传感器反馈状态、总线传递过来的信号状态。

优选地，控制器的输出状态包括电机状态、显示信息状态、总线发送出去的信号状态。

优选地，内部状态信息包括上电、复位、休眠模式状态。

本发明的有益效果是，当出现有疑问的问题时，可以快速确定具体是哪一方面的问题，避免都是在猜测而不是去解决问题，同时本发明也可运用到所有嵌入式系统的软件开发中去，缩短软件开发时间。

附图说明

图 1 ：本发明实施例的方法流程图。

具体实施方式

下面结合附图，将对本发明较佳实施例进行更详细的说明。

本发明用于对汽车电子软件开发过程中发现的问题定位分析的核心是，首先是要确认此控制器在分析时可能需要用到的状态信息，并把它们映射成具有唯一性的状态表；然后在控制器软件设计中增加状态变化记录模块和记录上传通讯机制，并建立一查询机制；遇到疑问时，通过查询机制获取状态变化记录，用以分析是否正常。

如图1所示为本发明一较佳实施例的方法流程图，结合车身控制器详细说明如下：

S101、确定要记录的状态信息