车辆制动性能检测实践中的经验总结

【中国分类号】v448.15+1

摘要：本文从对abs制动车辆、多轴车制动动力检测两方面给出了制动性能检测过程中需注意的问题，并创新出利用滚筒反力式制动检验台对多轴车检测制动协调时间的方法。同时也指出了平板式制动试验台在应用中的优、缺点。本文具有很强的现实意义。 关键词：制动性能 abs制动 检测

随着我国公路建设和道路运输业的飞速发展，汽车行驶速度的不断提高，近而汽车制动性能好坏对交通安全显得尤为重要。制动距离太长或者紧急制动时发生侧滑等都会造成交通事故。这对汽车运行管理部门如何运用新的检测技术动态监督汽车技术状况，提出了更高的要求。

汽车制动性能检测包括制动力、制动减速度、制动距离和制动时间四个指标。如何检测在长期的检测实践中总结了如下拙见。

一、在制动性能检测过程中需注意的一些问题

（一）对abs制动车辆的检测

检测车辆制动性能的常用设备主要有平板式制动台和滚筒式制动台。这两种制动台对带abs车辆的检测都存在着一定程度的不足。 在汽车检测行业中有观点认为滚筒式制动无法对带abs车辆的制动性能进行一个很准确的综合评估。其理由是由于带abs车辆车轮不能抱死，最大制动力难以反映，所以用滚筒式制动台不能检测带abs车辆的制动性能。车辆的abs系统一般要在行驶速度25～

40km/h以上采取紧急制动时才产生作用。在滚筒式制动台上虽然不足以达到车辆产生abs制动的条件，但检测结果是对车辆的正常制动力和制动力平衡的综合评价，制动检测台反映的是除车辆紧急制动情况外的制动性能参数。据笔者的经验，只要是能在正常制动时制动检测合格的车辆，其紧急制动时的制动性能更好。车辆的abs系统就其制动控制过程来看，评价其制动效果的指标应该是车辆在制动过程中的制动减速和制动跑偏程度，而不是所产生的制动力。 现在我们所用的平板式制动台，按标准只达到5～10km/h的检测速度，所以其检测结果也不能很准确地反映abs车辆的制动性能。因此，笔者认为平板式制动台能检abs车辆，而滚动式制动台不能控测，这也是一种认识上的误区。

（二）多轴车制动动力检测

公路干线上重大交通事故大多与重型货车有关，显然重型货车制动性能对道路交通安全起了极其重要的作用。重型货车都是多轴汽车，其后轴多是双驱动桥结构，重型汽车列车的半挂车也是多轴车，这些多轴车的长、宽、高都是充分利用了gb1589-20xx规定的外廊尺寸限值，由于车辆外型尺寸较长许多检测站受场地设备布置限制，不能对这部分车辆上线检测。

笔者所在公司对检测线进行全面改造时，充分考虑到重型汽车列车上线检测的要求，除所选设备单轴负荷达15t级外，检测线工位间距也设定为7m，满足汽车的检测要求。

检测线上制动力检测广泛采用的滚筒反力式制动检测台只能单轴

检测，虽然我们选用的带前后自由滚筒可解决双联轴检制要求的制动台，但不能同时检测各车轴；在汽车列车台试检测时，若牵引车和半挂车各车轴的制动力和制动力平衡满足了gb7258-20xx和

gb18565-20xx的要求，不等于汽车列车整体制动性就达到了标准的规定。

汽车列车制动性能还受到制动协调时间的影响。制动协调时间是汽车制动性能的一项重要评价指标，直接影响到制动距离的长短，对行车安全起着至关重要的作用。

制动协调时间应是指整车的制动协调时间，利用滚筒反力式制动控验台检测制动力是按每轴单独检测，并按标准的规定进行相关参数的评价。而作为制动协调时间，应是整车的制动协调时间，而非单指前轴或后轴的协调时间。因车辆原轴的制动力没有明确的限值要求，结合车辆安全行驶的实际制动情况标准中规定的制动协调时间，理解为整车制动协调时间是比较合理的。

我采用制动踏板力计测取作用计时开始，在制动力检测的全过程中，储存各轮制动力采样的各记录点（时间）所对应的制动力值，在同一时间各轮制动力值总和，达到受检车辆总重量与标准中限值的百分比之积的75％时，做为制动协调时间计算的终止点。因此采用制动踏板力计，只要对软件增加相应内容，就可以在滚筒反力式制动检验台上检测制动协调时间。我的方法弥补了大多数检测站对此项控测的空白。

二、平板式制动试验台的应用

平板式制动试验台是一种低速动态惯性式制动试验台，检验时汽车以5～10km/h速度开上平板，置变速器于空档并紧急制动。汽车在惯性作用下，通过车轮在平板上附加与制动力大小相等方向相反的作用力，使平板沿台纵向位移，经传感器送测出各车轮的制动力，并由指示装置显示检测结果。这种试验台结构简单，运动件少，用电量少，日常维护工作量少，提高了工作可靠性，测试过程与实际路测条件较接近，反映了车辆的实际制动性能，即能反映制动对轴荷转移带来的影响，以及汽车其他系统（如悬架结构，刚度等）对汽车制动性能的影响，该试验台不需要模拟汽车转动惯量，较容易将制动试验台与轮重仪、侧滑仪组合在一起，使车辆测试方便且效率高。

平板式制动试验台其优越性已逐渐被国内有关管理部门及检测部门所认识并广泛应用。笔者所在的公司经多年实践应用，发现仍然存在一些问题，需要改进和注意。

（一）测试重复性差

在检验的外界环境不足的情况下，重复性主要受检测员的踩制动习惯影响。从理论上讲，制动初速度的大小对测量值没有直接影响，根据牛顿力学第二定律（f＝ma，力的大小与加速度成正比），在制动过程中，由于质量不变，当加速度最大时，力达到最大，所以制动力的大小与初速度无直接关系，而跟速度的变化有关。当然初速度也不能过高或过低，gb7258-20xx规定采用平板式制动台测试时车辆行驶速度为5～10hm/h，车速高不安全，而且由于制动距离过

长不易将车辆停在平板上影响测试，车速太低则不足以产生足够的制动减速度影响测试准确，在平板式制动台测试制动性能时，要求检测员迅速制动，在汽车减速过程中减速度最大的点就是制动力最大的点，制动时汽车减速度的变化过程就是汽车制动力变化过程。因此，测试重复性差与检测员紧急制动的过程有很大关系，由于检测员动作不一致会造成检测结果重复性差。经过对检测员进行培训，基本上保证了检测的准确性。

（二）检测传感器对检测结果的影响

gb7258-20xx已明确使用平板式制动试验台检测方法。笔者所在公司在对检测线进行技术升级改造时小车线选用平板式制动试验台。实践发现平板式制动试验台对检测员的操作要求较高，其动作要规范准确；另外，制动台的传感器精度对测试结果的影响也较大。通常，传感器的测试精确度在量程的1/3～2/3区间是最高而且是较稳定的，偏离此区域就会出现离散现象，产生测试结果不稳定和重复性差等情况。原来我们的试验台按大部分被检测车为轴荷1t进行设计，与实际使用情况比较轴荷偏少，影响检测准确性，原来生产厂家将设备改为轴荷1.5t级，则检测结果稳定性和重复性大幅度提高。

由此亦可以看出，由于平板式制动台受各种使用条件的影响比较大，因此同一台设备最好只检测近似轴荷、轴距、宽度的车型，这对于机动车检测站需要多种车型检测是一个需要考虑的问题。另外，生产厂家如何提供精度高且工作稳定的传感器和检测电路也是

今后需要解决的问题。

第二篇：性能测试经验总结

第一步：计划测试

1、明确压力点，根据压力点设计多少种场景组合

2、把文档（包括多少种场景组合、场景与场景组合条件的对应表）写好

3、如果监测UNIX机器，在被监测的机器需要安装监测Unix的进程

4、让开发人员帮助我们准备测试数据或他们写相关的文档我们来准备数据

5、让开发人员做一个恢复数据的脚本，以便我们每次测试的时候都能有一个相同的环境

6、针对每一个模块包括四个子文件夹：如模块A下包括“脚本”“场景”“结果”“图表” 四个子文件夹，每个子文件夹储存对应的文件，如下表所示

其中：结果名“1场景”是在场景中的“Results Setting”中设置的，具体的设置见“建立场景”部分，这里也可以有另外一种方法：在打开模板设置，如下：

选中“Automatically save the session as:”并且在“%ResultDir%”后面填写你想保存的文件名，当你打开某个lrr文件时，系统自动在当前目录中生成一个文件保存分析图表，如下图所示：

第二步：生成测试脚本

1、把登陆部分放到“vuser_init”部分,把需要测试的内容部分放到“Action”部

分执行；但是如果是模拟多个用户登陆系统，则要把登陆部分放到Action部分来实现

2、录制脚本后，想查询某个函数的原型，按“F1”键

3、确认脚本中哪些参数是需要进行参数化的（最好能可以和开发人员一起确认）

4、在脚本参数化时把函数web_submit_data()中的ITEMDATA后面的数据参数

化，因为这些数据是传递给服务器的，当然也可以把一个函数中的所有相同变量都替换掉

5、脚本中无用的部分用“/*”“*/”“//”注释掉，但最好不要删除

6、调试脚本遵循以下原则：

确认在VU里SUSI（单用户单循环次数single user & single iteration）

确认在VU里SUMI（单用户多循环次数single user & multi iteration）

确认在controller中MUSI（多用户单循环次数multi user & single iteration） 确认在controller中MUMI（多用户多循环次数 multi user & multi iteration）

7、事务的名称取的有意义便于事务之间的区分，把所有的事务名都记录在一起，

便于在测试结果概要中区分它们，这要写成一个表：某次测试有哪些模块，每个模块中有哪些事务(见对应的“关系表”)

8、在“Parameter List”中可以选择参数类型“Random Number”，

使某一个参数取设定的范围内的随机值

第三步：建立场景

1、 把场景名称编号，并制定出一份场景名称和场景条件组合的对应表。比如，场景m对应

于“某一模块_xx个vu _分z台machine”(见“关系表”中的例子)

2、 根据上面的对应表把场景设置好，需要设置的要素如下：总体多少个用户、分多少个组、

每个组有多少个用户、分几台机器运行、每个脚本迭代多少次、是否回放think time时间、检查Parameter List中每个参数设置是否正确、参数从表中取值间隔是否正确、是否选中“Initialize all Vusers before Run”

3、 测试结果应该保存为“m场景0，m场景1,…”

4、 把虚拟用户分散到几台机器上和在一台机器上面都要进行测试，因为有可以效果不同

5、 场景中如果有需要改动的地方，必须新建一个场景(建议使用“另存为”，然后再修改结

果文件名，再选择相应的脚本)，并把场景按顺序编号，先维护好场景与场景组合条件的对应表，以便以后的查找，并且在结果“Results Setting”中设置的结果名与场景名相同。建议在“Results Setting”中选中“Automatically create a results directory for each scenario execution”让它每次自动累加，不建议选中“Automatically overwrite existing results directory without prompting for confirmation”，因为我们不要覆盖掉以前的测试结果，把它保存下来以便有个根据。

6、 需要注意的地方：当在“Parameter List”中的“Select next row”选中“Unique”时，如

果再在“Edit Schedule\Schedule by Scenario\Duration”中选中第二项“Run for XX after the ramp up has been completed”时系统就会报错，提示“Unique”类型不相符。

7、 在“Run-time Setting”设置中，“General”中的“Pacing”非常有用，可以设置每次迭代

之间相隔多少时间，也可以是随机的取值

8、 建议：把“Parameter List”和“Run-time Setting”中的所有设置都搞熟悉，这样便于以

后对脚本和场景进行设置

9、 设计“Parameter List”时的小技巧：即在“Allocate X values for each Vuser”时，尽量

把它的间隔在数据容许的范围内取大些，这样可以做从一次迭代到最大值迭代，而且对脚本没有什么影响

10、当一个脚本中有多个事务，在事务前面增加集合点时需要一点技巧。或者我们把脚本复

制几个，或者我这样做：测试前面的事务的压力时，把后面的事务前的集合点设置为不激活状态；在测试后面的事务的压力时，把前面的事务的集合点设置为不激活状态，另外最好不选中Initialize all Vusers before Run，具体参见Controller中的“Scenario/Rendezvous”，及用户手册(按F1)

11、把持续时间从最后60秒改为整个场景的时间，右键单击某个图，选择“Configue”，修 改Graph Time即可

12、每次从一个场景修改后保存为另一个场景时别忘记把结果保存文件名修改相对应的文件名。在设置结果保存文件名时有一个技巧：如果你打开这个窗口时，点击确定则系统会

默认以“4场景2”为基点向后加“4场景20”“4场景21”等等，但是如果你把结果文件名后面的数据去掉，改为“4场景”，点击确定后，系统会自动搜索是以“4场景”开头的文件名，并在它的后面继续增加，比如把它改为“4场景”时，下次结果保存在“4场景3”中。而且他在搜索的时候搜索以“4场景”开头的文件名，从0开始，有的话就不取代而跳过，没有的话就取代。

第四步：运行场景

1、 运行场景前需要注意的事项：每个组的虚拟用户数、迭代次数、think time、参数化时的

取值间隔、执行恢复数据的脚本、确认虚拟机的LoadRunner Agent Service打开

2、 如果监测Unix，运行场景前需要启动监测Unix进程，启动的命令“rpc.rstatd”、查看这

个进程是否启动的命令“rpcinfo –p”

3、 运行前使Generator机器处理Ready状态

4、 确认被监测的机器已经连接上去，并且添加自己所需要的计数器

5、 运行之前一定要确认系统中压力点的数据量是多少

6、 确认以上都正确时再运行测试场景

第五步：监视场景

1

、打开

Transactions”，可以随时观察到事务的运行状态 “Passed Transactions”或“Failed

第六步：分析测试结果

1、 打开Analysis后，把经过数据处理的结果图表保存到“图表”文件夹，并且文件名和场

景名、结果名相同，这样便于以后的查阅。也可以省去每次进行数据处理的时间。

2、 可以通过点击界面上的“View Run Time Setting”可以看到此场景运行时的一些场景

设置

3、 在关联图表时可以自动调节每个元素的比例，点击右键，选

择

即可

4、 每次测试结束后确认所做的操作是正确的，确认正确后再分析结果

5、 在结果文件夹中为每个场景建立一个文档，把每次运行时的情况记录下来以便于写测试

报告，尤其运行错误的原因记录下来，并把开发人员所做的修改也记录下来以便知道开发人员做了些什么修改

6、 在分析运行结果时可以把几个结果合在一起进行比较，打开如下“Cross with Result…”

即可，然后增加一个运行结果，这样就可以把你所需要的结果放到一起比较了