工业控制系统的实时性保障是相应装备可靠运行的 核心挑战。本研究基于 Isagraf平台构建的工控系统采用确定性任务调度机制，在 Linux 环境下实现周期性任务执行（典型周期 50-100ms）。硬实时约束下，当任务执行时间超过预设周期时，将触发系统级失效，表现为：①启动阶段死锁；②运行时任务队列溢出；③外部设备通信中断。

实证案例表明，某设备项目将从 50ms 调整至 100ms后，系统启动正常运行，说明程序本身可运行，只是由于程序实际运行时间过长，超过了固定扫描周期。对比以往项目负载，推测是由于系统运行的负载率过高导致了程序无法正常启动。

LINUX 系统负载率可通过系统平均负载和 CPU 使用率这两个指标来判定。系统平均负载表征待处理任务队列长度，CPU 使用率表征任务处理资源占用率。

系统平均负载指当前 CPU 运行的进程数和与当前运行进程抢夺 CPU 的可运行进程数目总和。CPU 使用率是以时间维度来计算的 CPU 使用率。两个指标都是越低表示负载率越低。

1 研究目的

为了程序稳定流畅地运行，需要尽可能地降低软件运行负载，缩短代码的实际扫描周期。

根据已正常运行项目，制定优化的目标：①设备正常运行过程中平均负载控制在 2 以内；②CPU 占用率在60%以内，程序执行周期不超过设定固定周期的 2/3。

2 研究思路

为降低设备程序的负载率，从两个方向寻找解决方法：一是反向对比，当前程序和以往项目差别；二是从正向分析，分析当前程序的软件架构。在以往的代码编程中，未出现初始程序无法启动的情况。

正常项目代码现状：编组少，2-3 编组。中间变量较少，大量使用原始通讯协议结构体中的原始变量。只做必备的功能，和记录少量的车辆关键信息。

高负载项目程序特点：①软件架构，通讯数据包增多，输入-中间变量-输出，需求功能之间独立；②编组变长，超过 4 编组，交互信息增多；③功能变化，增加内部记录，新增部分设备，新增功能。由此项目代码量急剧增多，导致了程序运行周期变长，设备负载率过高。

其次是分析现有项目的软件架构特点，寻找可降低负载率的可能措施。解决问题的原则：①减少不必要的服务进程；②缩减不必要的系统设置；③用更简单的代码实现相同的功能；④缩减代码量。

3 软件架构

工控机应用软件运行架构如图 1 所示。

图 1 工控机应用软件架构图

应用软件用于进行通讯参数初始化；通讯数据处理及各类逻辑的处理；系统配置文件，用于配置GW 的以太网（TRDP和UDP）通讯功能；底层固件包括设备驱动及Linux 内核。

4 分析及测试

分析软件对负载的影响因素，分析每个进程的作用及改进方法，并测试改进措施。

4.1 软件因素分析

采用鱼骨图分析影响因素，如图 2 所示。

图 2 软件架构鱼骨图分析

从系统配置服务和应用程序（即需求实现的代码）两个方面优化。

表 1 程序安装包系统配置

系统配置文件构成如表 1 所示，可改进的地方在系统配置文件和应用软件上。其中系统配置文件可修改配置的服务和进程，应用软件可修改通讯端口、函数、代码数量、运行周期、运行方式等。尽量精简不必要的设置，减少运行的进程。

负载来源于输入的软件包及其运行环境。当未放入TIC 代码时，则没有负载，负载来源于软件代码的运行启动。因此精简应用程序也同样重要。

应用程序示例包括接口协议的配置、运行周期的设置、逻辑运算和变量赋值等。如图 3 所示。分析上述因素，筛选出使能变量、Retain、板卡状态作为改进的重点。

图 3 工控机应用应用软件构成架构分解示例

4.2 系统配置降负载

存在进程设定 “ 锁定变量不可被更改 ”———VAR_LOCKING DISABLED，该进程适用于程序代码量少的在线调试，可在线更改被锁定的变量。

该进程打开时，需要删减大量代码才可运行，否则需要修改程序的固定扫描周期，从 50ms 改为 100ms 或200ms。占用大量内存，导致程序无法启动。车辆正式运行时，该功能可删除。

表 2 使用 retain 前的负载数据

表 3 取代 retain 后的负载数据（未屏蔽进程）

存在两种失电保存变量的方法，retain 脚本和变量自带属性。retain 的功能在于当程序失电后，保存的变量仍可保存。该功能可用变量的自带掉电保存属性替代。删除 retain 文件，修改前后效果如表 2 和表 3。LINUX 系统的一分钟平均负载平均值，从 3.98 下降至 2.84，下降 28.6%；CPU 的负载，从 60%下降至 55.6%，下降 7.33%。对比可知替换 retain 脚本，可较大幅度地降低负载。

表 4 屏蔽获取板卡进程后的负载数据

表 3 数据未屏蔽获取板卡进程，进一步地，屏蔽获取板卡进程如表 4 所示。

屏蔽获取板卡进程，修改前后对比：LINUX 系统的一分钟平均负载平均值，从 2.84 下降至 2.51，下降 11.82%；CPU 的负载，从 55.6%下降至 48.1%，下降 13.49%。可知屏蔽获取板卡状态进程，可极大降低负载。

4.3 应用软件降负载措施

优化程序算法，尽可能精简单个扫描周期内的代码运行量。测试删减代码后，随着代码量的减小可线性地降低负载率。具体措施如下：

1"规范程序编程规范：变量命名规范、结构体命名，代码格式；明确输入和输出。

2"删除多余变量：前期程序编程时，预留和使用的变量，后续没在使用，为了减少这部分程序扫描负载和周期，将多余的变量进行删除；运用 excel 表格工具，刷选出 mdb文件中用到的变量，使用 vlookup 函数匹配，筛选出协议里使用到的变量。

3"在输出赋值及判断时：对编组数量进行优化，避免无效赋值；不做编组冗余的代码赋值。

4"利用不同周期赋值：分周期处理，分散赋值；对失电后读写变量组、内部记 录 laser、VOBC赋值、显示屏赋值等。

5"涉及到计算和复杂函数的相关程序优化：代码精简准确，利用已有函数和功能块，避免重复创建；删除多余变量组长度。

6"精简 LINUX 系统的服务进程：关闭系统不必要进程服务，如 modbus、IO 的电压阈值设置等。

7"利用已有的函数：删除重复赋值语句，不必要赋值语句。

8"对于同一个变量赋值集中：列明变量所有条件，集中赋值，避免前被后覆盖的问题。

9"用结构体进行批量赋值：一条可取代上千条赋值语句；TRDP 分包，用结构体记录取代单条代码赋值记录；能采用以太网结构体赋值的地方，尽量采用结构体赋值；如显示屏的输出、内部记录、TRDP 的输出等。

10"优化程序架构：明确功能之间的界限，明确输入和输出；避免需求的相互交叉。

11"减少配线，减少变量组长度，减少进程。

应用软件降负载总结：1"避免使用位偏移；2"优化/使用自带函数等；3"用函数替代重复代码；4"精简逻辑判断；5"避免重复赋值/减少预留；6"减少赋值；7"用结构体替代大批量的赋值。

5 总结及展望

影响程序运行负载的因素众多，本文从软件层面对影响因素进行分析及测试，遵循以下原则：①精简进程，只开启必要的；②在保证功能实现的前提下，缩减代码量。

存在一些矛盾点在后续的程序开发中需要考虑：①明确的输入输出，会增加许多中间变量，增加负载；②新功能，会增加通讯和逻辑处理，增加负载；③长多编组车辆，及更多系统加入车辆，交互处理的信息，相应地代码量成倍增加。后续降负载判断标准可增加程序运行周期，精简每个程序块运行时间。也可寻求更高效的网络架构，更高效的网络安全通讯协议；寻找可替代的高性能硬件及软件平台。

原文刊载于《价值工程》 作者：比亚迪通信信号有限公司 刘赛武 陈艳军 成智华 杨丽娜 闫本正