简介：ISO 8373-2021是国际标准化组织发布的机器人领域最新术语标准，面向工业机器人研究者、设计制造人员、服务机器人开发者与标准化工作者，旨在统一全球范围内对工业机器人和服务机器人的定义与术语，解决行业沟通中的概念歧义。压缩包包含1个PDF文件，约2.25MB，为标准正文的电子版，内容覆盖通用术语、机械结构、几何学与运动学、编程与控制、性能、感知与导航、模块化等章节，可离线检索查阅。该资源已有1038人学习下载。标准详细定义了“关节”“末端执行器”“自主性”“人机协作”“安全停止功能”等关键概念，并涉及控制器、传感器、通信协议等术语，有助于研发人员准确理解并规范应用机器人词汇，促进技术交流与系统互操作性。作为ISO 8373的第三版（2021-11发布），该标准对机器人行业的技术创新和标准化建设具有重要参考价值。
1. 机器人词汇标准到底在规范什么：ISO 8373-2021 解决的不只是“怎么叫”
某次做复合机器人需求评审，机械工程师说“这台设备自由度不够”，算法工程师理解为运动学树上的独立运动变量，电气工程师以为是伺服轴数不够，三个人在会议室里争了二十分钟，最后发现说的其实是三件事。这种场面在机器人团队里并不少见，而最新的机器人词汇标准 ISO 8373-2021 要解决的正是这种“同词不同义”的沟通成本。它不是设计规范，不告诉你臂长该做多长、关节该用多大电机，它把机器人领域最常用的一批术语重新钉死，让跨团队、跨公司、跨文档的沟通有一个公共基准。这篇笔记从一线工程师视角拆开它：2012 版到 2021 版有哪些值得你注意的变化，怎么把标准条款整理成研发团队能直接用的术语表，以及落地时最常踩的几个坑。适合正在做机器人本体、产品手册、招标应答和跨团队评审的从业者。
2. 从 2012 到 2021：新词汇标准为什么影响你的评审与采购
ISO 8373 的 2021 版不是把 2012 版换个封面就发布的。过去十年里机器人形态发生了明显变化：移动底盘加机械臂的复合机器人成为主流形态，协作机器人从概念变成货架产品，服务机器人进入物流、医疗、商用场景。旧版本里很多术语是为传统工业机器人准备的，面对这些新形态时出现了大量“找不到准确词”的情况，各团队只能自己造词或用市场宣传词顶上，时间一长，文档里的术语体系就乱了。
新版词汇标准在我看来最重要的动作，是把机器人定义和分类的框架从“以工业机器人为中心”调整为“同时覆盖工业与服务两大类”，并且把移动操纵这类复合形态放进了正式术语体系。这个改动对工程师的直接价值不是“词汇变严谨了”这种抽象好处，而是当你做选型对比表、写技术协议、评审算法方案时，每个名词都对应一个明确对象，不再出现“我说的机械手和你说的机械手不是同一个东西”的反复确认。
2.1 机器人定义收紧：工业、服务与移动操纵机器人怎么区分
旧版定义里，很多说明文字默认机器人是固定在产线上的工业操纵设备。而 2021 版把“机器人”这个上位词定义得更加通用，下面按应用场景细分出工业机器人、服务机器人、移动操纵机器人等术语。工程上的直接后果是：你的项目到底用哪一组术语去描述，不再是你自己拍脑袋的事，而是有一个公共约定。
我一般会在项目启动时先做一次“产品归类”动作，规则很简单：按工作环境和任务性质判断。固定安装、执行重复加工任务的是工业机器人；为人类或设备提供服务、在非结构环境下工作的是服务机器人；既有移动底盘又有操作臂、需要连续完成移动和抓取的是移动操纵机器人。带机械臂的 AGV 就属于最后一种，写方案时不要只写“AGV+六轴臂”，规范词是移动操纵机器人，这个词一旦用上，你的自由度描述、坐标系定义、末端执行器描述都要跟着该术语体系走。
归类这一步看起来简单，实际影响很大。采购对比表里如果把复合机器人归成“AGV 加上机械臂”，供应商就会各按各的标准报参数，有人说轴数、有人说自由度、有人说负载能力，最后比价就变成了鸡同鸭讲。反过来，如果你在需求文档第一条就写明“本设备属于移动操纵机器人，术语定义遵循 ISO 8373-2021”，所有供应商必须按同一套词义来应答，偏离太远的说明可以直接判为不响应。
2.2 协作与位姿术语进入正典：评审时先对齐这些词
2021 版对协作机器人相关术语的梳理是一个值得单独说清的变化。过去团队的评审里经常出现“这是协作机器人所以不需要安全围栏”这种说法，把“协作”当成一个安全等级来理解。实际上词汇标准定义的协作机器人是一种设计与人共融工作的机器人，真正判断安全性要依据另外的协作安全技术规范。换句话说，术语术语标准里看清楚“协作”定义之后，你至少不会把词汇定义当成安全结论写进验收报告。
另一个被新版梳理清楚的词是位姿（pose）。它的定义是位置与姿态的合成量，不是单纯的坐标点。很多开发文档里把位姿写成一串数字，比如 100, 200, 300, 30, 45, 60。这串数字里前三个是位置，后三个是姿态角，但如果你不写依据哪个坐标系、旋转顺序是什么，这串数字没有任何可复现性。按照词汇标准的定义方式来审查，评审时要求文字图纸至少包含：位姿所在坐标系、平移分量单位、姿态表示法。这几项配齐，机械端和算法端对同一个点位表的理解才会一致。
评审会上另一个常见分歧是“路径（path）”和“轨迹（trajectory）”混用。词汇标准里路径强调空间位置的序列，轨迹会带上时间与速度信息。这个区别直接决定控制算法接口怎么设计：路径是纯几何问题，轨迹是时间规划问题。我见过一个项目把路径规划模块和时间最优规划写成同一个接口，结果调参时完全分不清效果变差是几何问题还是速度问题。
2.3 旧文档迁移：老图纸、老说明书里的术语怎么办
大多数团队不是从零开始用 ISO 8373-2021 的，手里攒着旧版命名习惯积累下来的图纸、专利、产品手册和技术协议。这些存量文档不会因为新标准发布就自动失效，但如果不做迁移，新旧文档混用会让后进来的工程师十分痛苦。我建议用一张“旧词映射表”来过渡，前端时间不追求一次改完，先保证所有新增文档用新词，存量文档用映射表完成翻译对照。
我做过一张内部映射表用于存量迁移，结构如下：
| 旧文档常见写法 | ISO 8373-2021 方向性建议 | 迁移注意点 |
|---|---|---|
| 机械手 | 操纵器（manipulator） | 旧词太宽泛，操纵器专指臂体部分，不包含控制系统 |
| 姿态 | 姿态（orientation）或位置姿态合称位姿 | 旧文档里姿态经常同时指“朝向”和“位姿”，要按上下文拆 |
| 自由度 | 运动自由度 | 保留“自由度”术语，但明确是否包含移动平台自由度 |
| 轴数 | 关节轴数 | 轴数和自由度不是一回事，详见第 4 章 |
| 工作范围 | 工作空间（work space） | 注意标准里对工作空间的表示法有约定，不要只写一个半径 |
迁移时最需要注意的是：不能只把老文档里的英文词替换掉，配套参数表的含义判断也要同步更新。比如旧文档写“负载能力”，新术语体系下要考虑是额定负载还是极限负载，定义来源不同，数值可能差出两倍。每次迁移只改词不核参数，等于把错误再用新词汇复述一遍。
3. 把标准条款落成研发可用的术语表：从官方文本到扫文档的脚本
标准条款写得再清楚，如果不变成团队日常使用的工具，价值就停在 PDF 里。我推荐的做法是建立一份团队内部中英对照术语表，再配两个脚本去扫设计文档和报价文档，把术语不一致暴露在评审之前。这套流程做下来，术语对齐就不依赖某个人记性好，而是依赖一套可重复执行的工具。
3.1 官方文本获取与使用边界
首先明确文本来源。ISO 8373-2021 的正式文本需要通过官方渠道获取，大多数工程团队走公司订阅库或者按单份购买流程。部分国家会有采用这套标准的本地版本，内容和术语对照通常保持一致，但条款编号可能有差异。具体买哪一份，取决于你的文档引用习惯：如果产品要出口，直接引用 ISO 版本；如果主要在国内流转，也可以采用本地采标版。无论选哪种，我建议以官方 PDF 为准，不要用二手网站的转贴内容建术语表。
这里有一个版权与合规边界要提醒：标准正文不能原样复制进公司公开知识库。正当做法是建立一份“转述+引用”式词表，即自己写定义摘要，并标注来源编号。内部研发用没问题，但别把整段条款贴到无法控制流转范围的共享目录里。我见过有公司因此在供应商审计时被要求下架内部资料，属于完全能避免的麻烦。
3.2 建表：字段设计与批量去重
术语表我建议用 CSV 存，方便脚本处理和人工编辑。字段不用设计得太复杂，六列足够：
term_en,term_zh,definition_summary,source,status,note robot,机器人,自动控制的、可重新编程的多用途操纵设备,ISO 8373:2021,enabled, manipulator,操纵器,机器人的机械本体部分，通常指臂与关节结构,ISO 8373:2021,enabled, end effector,末端执行器,连接在操纵器腕部用于执行作业的装置,ISO 8373:2021,enabled, pose,位姿,位置与姿态的合成量,ISO 8373:2021,enabled,注意与position区分 orientation,姿态,物体在空间中相对于参考坐标系的朝向,ISO 8373:2021,enabled,旧文档常误用为位姿 degree of freedom,运动自由度,描述机器人运动能力的独立运动变量数,ISO 8373:2021,enabled,不写作轴数六列字段里，term_en 是全表唯一键，term_zh 允许一英多中但要尽量收敛。definition_summary 写转述摘要，不要复制原文。source 保留标准号和版本信息，以后升级版本时可以基于该字段做影响分析。status 有 enabled 和 deprecated 两个值，迁移期老词保留为 deprecated，方便脚本同时识别新旧两套词。note 列留给工程备注，比如“和 position 区分”这类团队内特殊约定。
建表后第一件事是去重，我写过一段简单的 Python 脚本来做：
import csv def check_duplicates(csv_path): en_seen = {} zh_seen = {} with open(csv_path, encoding="utf-8-sig") as f: reader = csv.DictReader(f) rows = list(reader) for row in rows: en = row["term_en"].strip().lower() zh = row["term_zh"].strip() en_seen.setdefault(en, []).append(row) zh_seen.setdefault(zh, []).append(row) print("=== 英文术语重复检查 ===") for term, hits in en_seen.items(): if len(hits) > 1: print(f"{term}: {len(hits)} 条") print("=== 中文术语重复检查 ===") for term, hits in zh_seen.items(): if len(hits) > 1: print(f"{term}: {len(hits)} 条，涉及 {[h['term_en'] for h in hits]}") check_duplicates("robot_terms.csv")这段脚本处理的 csv 文件编码是 utf-8-sig，因为很多团队用 Excel 编辑 CSV，不带 BOM 时中文会被 pandas 之类工具读成乱码。setdefault 的作用是把同一个英文术语出现的所有行收集到列表里，最终打印出所有存在重复的项。中英文重复检查都要做：英文重复说明同一术语被多个人录了多次，中文重复更要警觉，因为它意味着两个不同英文术语被翻了同一个中文词，这是文档歧义的根源。脚本跑完，把重复项人工合并之后再继续做扫描。
3.3 用词表反查设计文档：两类定义冲突怎么自动发现
词表建好只是第一步，真正有价值的是拿它去扫描你们已有的设计文档、标书和技术协议。扫描能自动发现两类高频冲突。
第一类是“一英多中”：同一个英文术语 position，有人译成“位置”，有人译成“点位”，在旧文档里同时出现。第二类是“一中对多英”：orientation 和 attitude 都被译成“姿态”，但实际描述的不是同一件事。人工去通读文档找这两类问题太低效，我一般用脚本把命中术语的上下文行全部打印出来，交给作者确认。
import csv, glob def load_terms(csv_path): terms = [] with open(csv_path, encoding="utf-8-sig") as f: reader = csv.DictReader(f) for row in reader: terms.append((row["term_en"].strip(), row["term_zh"].strip())) return terms def scan_docs(term_list, doc_paths): from collections import Counter hit_counter = Counter() context_log = [] for path in doc_paths: with open(path, encoding="utf-8", errors="ignore") as f: lines = f.readlines() for line_no, line in enumerate(lines, 1): for en, zh in term_list: if en in line or zh in line: hit_counter[(en, zh)] += 1 if len(context_log) < 200: context_log.append((path, line_no, en, zh, line.strip())) return hit_counter, context_log terms = load_terms("robot_terms.csv") docs = glob.glob("specs/**/*.txt", recursive=True) hit_counter, context_log = scan_docs(terms, docs) for (en, zh), count in hit_counter.most_common(20): print(f"{en} / {zh}: {count} 次") print("=== 上下文样本 ===") for path, line_no, en, zh, text in context_log[:30]: print(f"{path}:{line_no} [{en}/{zh}] {text[:80]}")这段脚本按行扫描 txt 文档，命中词表的任意英文或中文术语就记录一次。参数上值得注意的有两个：errors="ignore" 是为了跳过二进制乱码和特殊编码字符，防止脚本中途崩溃；context_log 加了 200 条上限，避免日志文件被高频词刷爆。扫描结果里出现频次高的关键词本身不说明有问题，重点要看的是一对术语在不同文档里的比例，比如 position 的中文译法在文档里同时出现“位置”和“点位”两种，这条记录就要拉出来做术语统一。
做完这一步，团队就有了一个可持续运行的机制：词表维护和文档扫描常态化，新文档在评审前跑一遍扫描，术语不干净不上会。
4. 落地路上的几个常见坑：现象、原因、解法
术语标准本身并不复杂，真正让团队翻车的是拿着新标准去套旧习惯时，那些看上去不起眼但后果严重的理解偏差。这一章把我在项目里见过最多的四类问题按现象、原因、解决的结构写清楚。
4.1 把自由度与轴数混为一谈
现象：投标文件里写“六轴自由度”，选型表里把关节轴数和运动自由度当成同一个指标对比。某次采购对比中，一家供应商报“6 轴自由度”，另一家报“移动平台 3 自由度+机械臂 6 自由度”，两家数值不同但都说自己是响应了同一份需求书。
原因：轴数是机械结构概念，指可驱动的关节轴数量，是实实在在的硬件配置；自由度在机器人运动学里有严格定义，指描述机器人运动所需独立运动变量的数目。二者在一定结构下数值可能相同，比如单独一台六轴关节机械臂，轴数和运动自由度都是 6，但加上移动底盘后就完全对不上了。
解决：技术协议里把两个词分开写，用“关节轴数”描述硬件配置，用“运动自由度”描述运动学指标。越是在复合机器人项目里越要强制这样写，因为移动平台通常提供 3 个自由度，机械臂提供 6 个，总自由度是 9，而不是两台设备轴数相加那么简单。评审时遇到写“自由度”不写计算依据的描述，直接退回补充说明。
4.2 位姿表达式的坐标系与旋转顺序缺失
现象：点位表里写“P1：100, 200, 300, 30, 45, 60”，机械工程师说这是基坐标系下的位置加欧拉角，算法工程师说我默认是工具坐标系加四元数，同一串数字进入仿真和实机是完全不同的效果。
原因：位姿的定义是位置与姿态的合成量，但标准只规定术语含义，不规定你用什么表示法。工程上欧拉角本身就有多种旋转顺序约定，ZYX、ZYZ、XYZ 结果都不一样，更不用说还有人写成象限角和四元数。
解决：文档里任何出现位姿数字的地方，旁边必须标注三个要素：参考坐标系、姿态表示法、旋转顺序或四元数格式。我一般会在图纸和协议模板的位姿表里预留三列固定字段，让填写人必须勾选，勾不出来的位姿数据视为无效输入。这个习惯能省掉后面标定阶段大量莫名其妙的偏差排查。
4.3 把协作机器人术语当成安全结论用
现象：有次评审一份产线改造方案，需求文档写着“采用协作机器人，可以取消安全围栏，实现人机共线”。安全工程师追问依据，回答是“协作机器人这个词的标准定义就是这么说的”。
原因：词汇标准里的协作机器人定义描述的是设计特征和预期用途，不是安全性能指标。机器人在协作场景下能做什么、不能做什么，由协作机器人安全相关技术规范另行规定，已经超出了词汇标准的管辖范围。定义里相对明确的只是“设计用于与人协作”，至于怎么协作、安全性如何保证，是安全标准回答的问题。
解决：方案文档里把两类表述分开写。描述产品类型时用“协作机器人”，描述安全策略时引用安全标准并具体写明协作模式和安全监控方案。语义上实在绕不开时，加一句“安全性能依据协作机器人安全技术规范执行”，避免把词汇定义当成安全背书。
4.4 把词汇标准当成设计规范引用
现象：机械评审时有人提出“位姿的定义里没说工作空间该标注限位距离，所以这个设计可以不写”，这属于把术语标准当设计标准用了。词汇标准只回答“这个词是什么意思”，不回答“你的设计应该达到什么指标”。
原因：标准体系里词汇标准和产品标准分工不同。词汇标准统一语言，性能限值和设计准则在对应的产品安全标准和性能标准里。引用一个词汇标准去支撑设计决策，属于引用层级错误，被专业审查人员看到会直接降低整份文档的可信度。
解决：建立引用习惯：术语定义引用 ISO 8373-2021，性能指标引用对应产品标准，安全要求引用安全规范，不要把来源写混。文档中同时出现“术语定义依据”和“性能限值依据”两个字段独立标注，能有效避免这种错位引用。
5. 进阶用法：把词汇标准嵌进需求评审与验收流程
最后这套用法适合团队已经建好术语表、跑通扫描脚本之后再用，把词汇标准从“工具书”变成“流程的一部分”。
5.1 评审前加一轮术语审计
把术语扫描前置到需求评审之前，不是评审看文档时顺手看，而是作为进入评审的前置条件。我在团队里定了一条规则：需求文档必须通过术语扫描脚本，存在“一英多中”或“一中对多英”的记录必须清零才能安排评审。第一次执行时大家觉得麻烦，跑了三次以后反而发现文档评审时间变短了，因为大量争论在评审前已经被脚本消除。
5.2 验收文档的术语一致性检查表格
验收阶段同样值得加一道检查，我建议用下面这张表配合自动化扫描做确认：
| 检查项 | 通过标准 | 责任角色 |
|---|---|---|
| 关键术语来源 | 机器人、操纵器、位姿等术语标注了 ISO 8373-2021 定义来源 | 技术文档负责人 |
| 术语表同步 | 验收文档中的术语与团队词表 enabled 状态一致 | 研发工程师 |
| 旧词残留 | deprecated 术语在产品手册和技术协议中无新增出现 | 文档工程师 |
| 位姿描述完整 | 所有点位表均包含坐标系、姿态表示法、旋转顺序/四元数格式 | 算法与机械共同确认 |
| 轴数与自由度 | 关节轴数和运动自由度分别描述，无混用 | 系统工程师 |
5.3 一个完整的文档扫描小工具
把前面两段脚本合并成一个小工具，入参是术语表和文档目录，出参是术语频次统计和上下文日志，就是一套很实用的内部基础设施。核心逻辑不外乎加载词表、逐行扫描、命中计数、输出上下文，真正要控制的是两个边界：一是编码兼容，读取旧文档时多做一次容错；二是日志量，防止高频词刷爆输出。跑过一批文档之后你会很快看出团队术语问题的集中区域，比如某个模块的文档总在姿态相关词上出错，就可以定向做一次术语培训。
我自己的习惯是每季度跑一次全量扫描，把结果和新加入的 deprecated 词对照，看历史问题是否回潮。这样做了半年，最大的收获不是文档变漂亮了，而是新同事进来就能直接看懂旧文档，不再需要找老员工逐词翻译黑话，这个隐性成本远比想象中大。
希望这套方法能帮到你，把 ISO 8373-2021 从书架上的 PDF 变成研发流程里真正起作用的那一环。
本文还有配套的精品资源，点击获取
