GB/T 45866-2025 土方机械 机器控制系统分层式软件架构 通用要求

　　ICS 53. 100 CCS P 97

　　中 华 人 民 共 和 国 国 家 标 准

　　GB/T 45866—2025

　　土方机械 机器控制系统分层式软件架构

　　通用要求

　　Earth-moving machinery—Layered softwarearchitecture formachinecontrol

　　system—Generalrequirements

　　2025-08-01发布 2026-02-01实施

　　国家市场监督管理总局国家标准化管理委员会

　　

　　发

　　

　　布

　　GB/T 45866—2025

　　目 次

　　前言 Ⅲ

　　1 范围 1

　　2 规范性引用文件 1

　　3 术语和定义 1

　　4 分层式软件架构的模块化设计原则 2

　　5 架构的描述 3

　　6 架构的功能要求 4

　　附录 A (资料性) 编码命名和注释 6

　　附录 B (资料性) 基于 UML 的应用层 、映射层和基础层模块结构示例 10

　　附录 C (资料性) 架构实现示例 11

　　参考文献 13

　　Ⅰ

　　GB/T 45866—2025

　　前 言

　　本文件按照 GB/T 1. 1—2020《标准化工作导则 第 1部分 :标准化文件的结构和起草规则》的规定起草 。

　　请注意本文件的某些内容可能涉及专利 。本文件的发布机构不承担识别专利的责任 。

　　本文件由中国机械工业联合会提出 。

　　本文件由全国土方机械标准化技术委员会(SAC/TC334)归 口 。

　　本文件起草单位 :江苏徐工国重实验室科技有限公司 、广西柳工机械股份有限公司 、山西太重智能采矿装备技术有限公司 、上海交通大学 、福建省威盛机械发展有限公司 、天津工程机械研究院有限公司 、临工重机股份有限公司 、山东肯石重工机械有限公司 、国机重工集团常林有限公司 、福建晋工新能源科技有限公司 、株洲变流技术国家工程研究中心有限公司 、北谷电子股份有限公司 。

　　本文件主 要 起 草 人 : 秦 浩 良 、王 己 林 、岳 海 峰 、王 亚 飞 、肖 自 能 、吴 红 丽 、高 振 华 、贺 广 民 、严 洁 银 、肖育波 、刘辉荣 、邓波 、宋天佳 、李泽星 、陈宝庆 。

　　Ⅲ

　　GB/T 45866—2025

　　土方机械 机器控制系统分层式软件架构

　　通用要求

　　1 范围

　　本文件规定了土方机械机器控制系统分层式软件架构的功能要求 ,确立了软件架构的结构组成 ,描述了应用层 、映射层和基础层组件的功能模块以及软件架构的设计流程 。

　　本文件适用于土方机械机器控制系统分层式软件架构的开发和设计 。

　　2 规范性引用文件

　　下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款 。其中 , 注 日期的引用文件 ,仅该日期对应的版本适用于本文件 ;不注日期的引用文件 ,其最新版本(包括所有的修改单) 适用于本文件 。

　　GB/T 8498 土方机械 基本类型 识别与术语

　　GB/T 28174. 2 统一建模语言(UML) 第 2部分 :上层结构

　　3 术语和定义

　　GB/T 8498界定的以及下列术语和定义适用于本文件 。

　　3. 1

　　机器控制系统 machinecontrolsystem

　　系统包含的组件需要满足系统的功能 ,包含传感器 、信号处理单元 、监控器 、控制和驱动器 ,或其中的几个部分 。

　　注 : 该系统的范围不仅限于电子控制 ,而是由完整的 系 统 设 备 相 关 的 功 能 定 义 。 因 此 , 它 一 般 包 括 电 子 、非 电 子 和连接设备 。包括机械的 ,液压的 ,光纤的或充气的组件/系统 。

　　3.2

　　模块 module

　　a) 离散的程序单位 。

　　b) 程序中一个或数个能合乎逻辑 ,且分开具有独立功能的部分 。

　　[来源 :GB/T 11457—2006,2. 977,有修改] 3.3

　　软件架构 softwarearchitecture

　　以模块 、模块之间的关系 、模块与环境之间的关系为内容的某一系统的基本组织结构 , 以及指导上述内容设计与演化的原理 。

　　3.4

　　分层式软件架构 layered softwarearchitecture

　　将软件架构按照功能进行有序的分组 ,从逻辑上将软件架构划分成多个遵循一定规则的集合(层) 。注 : 通过分层 , 限制软件架构不同功能模块间的依赖关系 ,使其以更松散的方式耦合 ,从而更易于维护 。

　　1

　　GB/T 45866—2025

　　3.5

　　可移植性 portability

　　系统或部件能从一种硬件或软件环境转换至另外一种环境的特性 。

　　[来源 :GB/T 11457—2006,2. 1149] 3.6

　　可维护性 maintainability

　　a) 软件系统或部件能被修改以排除故障 、改进性能或其他属性 , 以及适应环境变更的容易程度 。

　　b) 硬件系统或部件完成功能后 ,能恢复或存储回原状态的容易程度 。

　　[来源 :GB/T 11457—2006,2. 903,有修改] 3.7

　　应用层 application layer

　　实现机器特定作业要求且与硬件无关的控制逻辑程序的分层 。

　　注 : 根据模块的通用性分为控制逻辑层和基本功能层 ,控制逻辑层由满足客户需求的控制功能模块组成 ,基本功能层由通用模块组成 。

　　3. 8

　　映射层 mappinglayer

　　实现不同层级间数据 、指令或接口协议转换与协调的功能层 。

　　3.9

　　基础层 infrastructurelayer

　　面向硬件设备及底层资源的核心功能层 ,提供支持应用层和映射层的基础设施服务和数据存储 。

　　3. 10

　　组件 component

　　由单个或多个模块组成 ,软件系统中具有相对独立功能 、能明确辨识 、接 口 由规范指定 、和语境有明显依赖关系 、可独立部署的可组装软件实体 。

　　3. 11

　　端口 port

　　软件组件与外部环境交互的抽象接 口 。

　　4 分层式软件架构的模块化设计原则

　　4. 1 高内聚、低耦合原则

　　模块化设计遵守高内聚 、低耦合原则 。 除根据需要进行数据通信外 ,各模块不受其他模块的干扰或影响 。高内聚建议不将毫无关联的成分放入同一模块 ,低耦合建议不使一个模块过分依赖于其他模块的运行 , 当某个软件功能出现问题时 ,不影响其他软件功能的正常实现 。

　　4.2 软硬件分离原则

　　根据不同的模块功能从结构上划分 ,并将软件和硬件分离 ,宜独立设计 。

　　4.3 功能分离原则

　　按照功能不同划分土方机械控制系统分层式软件架构(简称架构)的模块 。

　　4.4 模块互换性原则

　　接口一致且具有相同功能的模块宜具有互换性 。

　　2

　　GB/T 45866—2025

　　5 架构的描述

　　5. 1 架构的结构组成

　　架构由应用层、映射层和基础层组成 ,如图 1所示 。应用层、映射层和基础层的命名和注释见附录 A。应用层、映射层和基础层应由相应的功能模块构成 。

　　图 1 控制系统架构的结构示意图

　　5.2 应用层的功能模块

　　5.2. 1 通用模块的信息

　　通用模块应包含模块名称 、模块功能 、模块连接表等信息 。

　　5.2.2 通用模块的分类

　　通用模块按照不同的功能分为信号变化模块 、双稳态模块 、计数模块 、定时模块 、数据处理模块 、数据转换模块 、交互模块 、运动控制模块等 ,宜根据需求扩充 。

　　示例 : 基于 UML 的应用层模块结构见附录 B 的 B. 1。

　　5.3 映射层的功能模块

　　5.3. 1 通用模块的信息

　　映射层模块应包含模块名称 、模块端口信息 、模块服务状态等信息 。

　　5.3.2 通用模块的分类

　　通用模块按照不同的接口类型分为数据接口 、事件接口 、服务接口 、动作接口 、配置接口等 ,宜根据需求扩充 。

　　示例 : 基于 UML 的映射层模块结构见 B. 2。

　　5.4 基础层的功能模块

　　5.4. 1 通用模块的信息

　　通用模块包括通道 、端口配置 、数据类型等信息 。基础层模块提供底层的硬件驱动程序 ,用来控制硬件资源的访问 ,描述基础层模块各方面的属性 。

　　3

　　GB/T 45866—2025

　　5.4.2 通用模块的分类

　　通用模块按照不同的驱动形式分为 IO 驱动 、通信驱动 、存储器驱动 、微控制器驱动 。示例 : 基于 UML 的基础层模块分类见 B. 3。

　　5.5 示例

　　架构的实现示例见附录 C。

　　5.6 设计流程

　　5.6. 1 概述

　　架构设计流程共分为 5个步骤 ,各个步骤之间的关系如图 2所示 。

　　图 2 架构设计流程图

　　5.6.2 需求分析

　　需求分析应梳理和整理用户提供的需求 ,提取其中的功能需求和非功能需求 。

　　5.6.3 确定关键需求

　　对功能需求和非功能需求进行综合权衡 ,确定关键需求 。

　　5.6.4 概念架构设计

　　概念架构设计应包含如何划分顶层系统和选型的类型 。

　　注 : 选型的类型包括架构风格选型 、开发技术选型 、集成技术选型和二次开发技术选型 。

　　5.6.5 细化架构设计

　　细化架构设计应依据概念架构设计模块之间的接口进行 ,宜分为逻辑视图 、进程视图 、实施视图 、部署视图等不同架构视图 。

　　5.6.6 架构验证

　　通过架构设计方案来评估架构是否合理 。把存在的 “风险 ”尽早发现并控制 ,并通过执行测试等手段判断 “风险 ”是否得到控制 。

　　6 架构的功能要求

　　6. 1 可拓展(裁剪)性要求

　　可拓展(裁剪)性要求如下 :

　　4

　　GB/T 45866—2025

　　a) 软件功能应方便地进行拓展或裁剪 ;

　　b) 软件功能的增加(裁剪)不应影响其他功能的实现 ;

　　c) 软件模块应对拓展(裁剪)开放 、对修改关闭 。

　　6.2 可移植性要求

　　可移植性要求如下 :

　　a) 软件应能在不同硬件平台 、相同编译环境下的代码移植 ,移植后代码功能一致 ;

　　b) 符合行业的标准接 口 。

　　注 : 软件的可移植性体现在应用层层面 。

　　6.3 可维护性要求

　　可维护性要求如下 :

　　a) 当功能模块出现缺陷时 ,应能进行模块的替换 ,修复缺陷 ;

　　b) 当发生故障时 ,应能进行诊断并判断故障的发生位置 。

　　5

　　GB/T 45866—2025

　　附 录 A

　　(资料性)

　　编码命名和注释

　　A. 1 通用规则

　　A. 1. 1 命名使用字母 、数字 、下划线(a~ z,A~ Z,0~ 9, ) ,并且只能以字母(a~ z,A~ Z) 或下划线开头 ,名称区分大小写 。

　　A. 1.2 名称宜简洁并且使用有意义的英文或简写 。

　　A. 1.3 命名规则宜在满足通用规则的基础上进行适当修改 。

　　A. 1.4 合理选用以下原则和方法进行缩写(见表 A. 1、表 A. 2、表 A. 3) 。

　　— 缩写原则 :

　　● 缩写保持一致性 ;

　　● 可加入注释来说明非通用的缩写 。

　　— 缩写方法 :

　　● 去掉所有的不在词头的元音字母 ,如 screen写成 scrn;

　　● 使用每个单词的前三个字母 ,如 Channel Activation写成 ChaAct,Release Indication写成RelInd;

　　● 使用变量名中每个有典型意义的单词进行缩写 ,如 CountofFailure写成 FailCnt;

　　● 去掉无用的单词后缀 ing,ed等 ,如 Paging Request写成 PagReq;

　　● 使用标准的或常用的缩写形式 ,如 BSIC(Base Station Identification Code) 、MAP(Mobile Application Part) 。

　　示例 : Sw(开关) 、Sig(信号)和 Ctrl(控制) 。

　　表 A. 1 数据类型前缀列表

　　数据类型

　　缩写

　　取值范围

　　说明

　　bool

　　x

　　False或 True

　　布尔

　　byte

　　by

　　0~ 255

　　字节

　　sint/int8

　　si

　　-128~ 127

　　有符号 8位整型

　　usint/uint8

　　usi

　　0~ 255

　　无符号 8位整型

　　int/int16

　　i

　　-32 767~ 32 767

　　有符号 16位整型

　　uint/uint16

　　ui

　　0~ 65 535

　　无符号 16位整型

　　dint/int32

　　di

　　-2 147483 648~ 2 147483 647

　　有符号 32位整型

　　udint/uint32

　　udi

　　0~ 42 949 672 954

　　无符号 32位整型

　　real/single/float

　　r

　　-3. 4* 1038 ~ +3. 4* 1038

　　32位实数类型

　　lreal/double

　　lr

　　-1. 7* 10308 ~ 1. 7* 10308

　　64位实数类型

　　6

　　GB/T 45866—2025

　　表 A.2 作用域后缀

　　作用域

　　缩写

　　说明

　　Global

　　G

　　全局变量

　　Local

　　L

　　局部变量

　　表 A.3 控制后缀

　　控制

　　缩写

　　说明

　　Input

　　I

　　输入 、需求

　　Output

　　O

　　输出 、供给

　　A.2 函数/功能块/模块的命名规则

　　A.2. 1 函数/功能块/模块的命名规则满足下列规则 ,示例见表 A. 4:

　　— 不使用下划线分割字段 ;

　　— 每个字段的首字母应该大写(特别的 , 当字段由多个名词组成时每个名词首字母都需要大写) ,其余小写 ;

　　— 名称总长度不得超过 25个字符 ;

　　— 当模块字段长度大于 15个字符时 ,建议参照 A. 1. 4 的缩写规则进行缩写 。

　　表 A.4 函数/功能块/模块命名举例

　　函数/模块含义

　　函数/模块命名

　　发动机速度控制

　　EngSpeedCtrl

　　发动机启动

　　EngStart

　　行走警示

　　WalkAlarm

　　A.2.2 映射层模块的命名宜以 RTE作为关键字 ,用以区分其他层级的模块 ,还要根据模块的数据来源 ,在模块命名上增加对应的标识 ,便于识别数据来源 。其命名规则如图 A. 1所示 。

　　RTE CAN

　　_

　　数据来源识别关键字 中间层识别关键字

　　图 A. 1 映射层模块名称命名规则示例

　　A.3 变量的命名规则

　　变量命名规则按下列规则 ,示例见表 A. 5:

　　— 中括号必选 ,小括号可选 ;

　　— 变量名=【数据类型】【变量描述】(作用域)(控制后缀) ;

　　— 变量总长度不得超过 25个字符 ;

　　7

　　GB/T 45866—2025

　　— 字母数字的组合 ,但不能以数字开头 ;

　　— 数据类型前缀标明一个变量的数据类型 ,全部小写字母 ,且必须用缩写 ,参考表 A. 1;

　　— 变量描述使用 “名词 ”或者 “名词 +动词 ”形式 ,一个或多个单词组成 ,每个单词的首字母或缩写首字母要大写 ;

　　— 变量描述在 15个字符以内不考虑缩写 ,超过 15个字符建议对变量描述进行缩写 ,缩写时按A. 1. 4 的缩写方法和缩写原则 ;

　　— 作用域后缀标明一个变量的可见范围 ;

　　— 局部变量时作用域后缀可选 ,全局变量时作用域后缀必选 ;

　　— 控制后缀表示针对该模块来说该变量的信号流向 。

　　表 A.5 变量命名举例

　　信号含义

　　信号类型

　　作用域

　　控制后缀

　　变量命名

　　发动机启动

　　bool

　　局部

　　Input

　　xEngineStartI

　　A.4 常量的命名规则

　　— 常量名=【常量“描述】”; “ ”

　　常量命名规则按下列规则 ,示例见表 A. 6:

　　— 常量描述使用 名词 或者 名词 +动词 形式 ,一个或多个单词组成 ,单词全部大写 ,单词与单词之间以单下划线进行分割 ;

　　— 常量名最长不得超过 25个字符 ;

　　— 常量描述在 15个字符以内不考虑缩写 ,超过 15个字符建议对常量描述进行缩写 ,缩写时应按A. 1. 4 的缩写方法和缩写原则 。

　　表 A.6 常量命名举例

　　信号含义

　　常量命名

　　最大转速

　　MAX_SPEED

　　A.5 接口的命名规则

　　接口命名规则按下列 ,示例见表 A. 7:

　　— 接口前缀固定使用 I ;

　　— 接口命名=【接口前“缀”】【接口描述】;

　　— 接口描述以字母开头 ,使用 “动词 ”或者 “动词 +名词 ”形式 ,接口描述的第一个字母大写 ;

　　— 接口命名最长不得超过 25个字符 ;

　　— 接口描述在 15个字符以内不考虑缩写 ,超过 15个字符建议对接口描述进行缩写 ,缩写时按A. 1. 4 的缩写方法和缩写原则 。

　　表 A.7 接口命名举例

　　信号含义

　　接口命名

　　闪烁信号接 口

　　IBlink

　　8

　　GB/T 45866—2025

　　A.6 注释

　　注释按下列规则 。

　　— 文件注释建议采用统一格式 ,说明性文件(. h文件 、. def文件等)注释规范推荐使用格式如下 :

　　Copyright(C) :公司名称 ;

　　FileName:代码文件名称 ;

　　Description:代码内容描述 ;

　　CurrentVersion:版本号 ,编写者 、修改者 、修改时间 、修改内容 ;

　　Historic Version:版本号 ,编写者 、修改者 、修改时间 、修改内容 。

　　— 源文件注释建议采用统一格式 ,源文件注释规范推荐使用格式如下 :

　　Function:函数名称 ;

　　Description:函数功能描述 ;

　　Input:输入参数说明 ;

　　Output:输出参数说明 ;

　　Return:函数返回值的说明 。

　　— 对于所有带有物理含义的变量 、常量 ,在声明时增加注释 ,说明其物理含义 。变量 、常量的注释放在其上方相邻位置或右方 。

　　— 注释的可读性 、可理解性 :

　　● 注释与所描述内容进行同样的缩排 ;

　　● 在一行代码或表达式的中间不建议插入注释 ;

　　● 在代码的功能 、意图层次上进行注释 ,提供有用 、额外的信息 ;

　　● 对分支语句(条件分支 、循环语句等)编写注释 ;

　　● 注释的内容要清楚 、明了 ,含义准确 , 防止注释二义性 。

　　— 语句的注释 :

　　codesys环境下使用 “( * … … * ) ”,c语言环境下使用 “/* … … * /”。

　　— 注释语言规范 :

　　注释建议只使用一种语言 ,本文件建议使用英文 。

　　— 其他 :

　　● 不使用嵌套的注释 ;

　　● 保持注释与代码的一致性 ,无用的注释应删除 ;

　　● 对单条语句代码的注释放在其上方或右方相邻位置 ;

　　● 避免在注释中使用非常用缩写 。

　　9

　　GB/T 45866—2025

　　附 录 B

　　(资料性)

　　基于 UML 的应用层、映射层和基础层模块结构示例

　　B. 1 基于 UML 的应用层模块结构如图 B. 1所示 。

　　图 B. 1 基于 UML 的应用层模块结构

　　B.2 基于 UML 的映射层模块结构如图 B. 2所示 。

　　图 B.2 基于 UML 的映射层模块结构

　　B.3 基于 UML 的基础层模块结构如图 B. 3所示 。

　　图 B.3 基于 UML 的基础层模块结构

　　10

　　GB/T 45866—2025

　　附 录 C (资料性)

　　架构实现示例

　　C. 1 Codesys分层式实现

　　在 Codesys开发环境中 ,应用层模块放置于应用层文件夹中 ,与底层相关的模块放置于基础层文件夹 ,连接应用层模块和基础层模块端口的模块放置于映射层文件夹 。 映射层代码用于应用层模块之间 、应用层模块与基础层模块之间的端口变量连接 ,见图 C. 1。

　　图 C. 1 Codesys分层式实现示例

　　C.2 C 语言分层式实现

　　在单片机 C程序编译环境中 , 由 AUTOSAR配置工具生成的基础层模块代码放置于 Bsw 文件夹里 , 由 Simulink生成的应用层模块代码放置于 Components文件夹里 ,应用层模块间 、应用层模块与基础层模 块 间 的 连 接 的 映 射 层 模 块 放 置 于 Generate文 件 夹 里 , 映 射 层 代 码 放 置 于 Rte. c 文 件 里 , 见图 C. 2。

　　11

　　GB/T 45866—2025

　　图 C.2 C 语言分层式实现示例

　　C.3 组件式开发分层式实现

　　在组件式开发方式中 ,基础软件提供任务 、流程 、IO、控制等接口规范化的组件;IO 配置工具 ,CAN配置工具等生成中间映射代码 ,屏蔽不同产品在部分功能实现上的差异 ,应用层利用组件实现功能和控制逻辑 ,见图 C. 3。

　　图 C.3 组件式开发分层式实现示例

　　12

　　GB/T 45866—2025

　　参 考 文 献

　　[1] GB/T 11457—2006 信息技术 软件工程术语

　　13