KUKA机器人车型调用分析程序开发

摘要

在工业机器人生产现场，车型切换、轨迹验证、工艺问题排查和项目交接都离不开对机器人程序调用关系的理解。传统做法主要依赖调试人员或维护人员逐个阅读 KUKA 机器人备份中的程序文件，这种方式虽然在小规模项目中可行，但在车型数量持续增加、调用层级不断加深的情况下，已经难以兼顾效率、准确性和知识沉淀。基于这一现实需求，本文在前一篇 KRL 文法分析报告的理论基础上，围绕“车型调用关系解析”这一明确目标，设计并实现了一套本地 Web 形态的 KUKA 机器人备份分析程序。

本文重点介绍该程序的工程实现思路，而不是重复展开编译原理推导。系统以 KUKA 机器人备份 zip 文件为输入，首先完成文件读取、路径筛选和元信息提取；随后将 .src 与 .dat 文件按照模块名进行耦合，形成统一的模块单元；在此基础上，借助 ANTLR4 生成的词法分析器和语法分析器完成程序结构识别，并围绕车型调用链条抽取 Cell 程序 -> P 程序 -> 车型代码 -> 车型程序 -> 轨迹程序 的层级关系；最后通过 Config 配置过滤基础模块和业务噪音，将结果以 JSON 图结构返回给前端，并进一步导出为适合存档和转发的 Excel 表格。

为兼顾可用性与工程可维护性，系统被划分为 krl-core 与 krl-web 两个主要模块。前者负责语言解析、文件加载、模块组织、调用关系抽取与 Excel 导出，后者负责配置管理、文件上传、同步分析接口以及前端静态页面交互。前端界面基于 Cytoscape 对调用关系进行可视化展示，并提供线体信息视图与车型信息视图；导出模块则基于 Apache POI 将图结构转换为“树形结构区 + 调用矩阵区”的 Excel 表达形式。本文将从输入、解析、过滤、展示与导出的完整链路出发，说明该程序如何将 KRL 语法分析能力落地为一套面向实际产线问题的本地 Web 工具。

关键词： KUKA；KRL；调用关系；本地 Web 软件；ANTLR4；Cytoscape；Apache POI

说明：本提纲仅介绍当前项目作为本地 Web 软件时的工程设计与实现，不涉及云端部署、服务治理或 server 模式。本报告包含kuka备份文件结构概述及如何从中获取相应信息、针对"车型调用关系解析"这一需求如何简化语法模型构建核心AST节点、最终的"调用关系"所对应的数据结构的设计思路、SpringBoot与用户交互的方法简述、cytoScape进行可视化的方法简述、Apache.poi导出Excel表的方法简述。

1. 背景介绍

• 由于柔性化生产的目标，一条线体往往有多个款式、甚至多个品牌的车型。
• 在车型导入更改调用关系时、机器人发生碰撞后轨迹验证时、工艺故障相关问题排查时，在这些种种场景下，都需要对车型调用、轨迹调用有清晰的了解。
• 目前厂房里车型数量众多、调用关系交错繁杂，且仍在不断导入新车型，难以仅仅依靠人工来高效、准确、及时的全线梳理轨迹和已导车型。
• 开沃厂房几乎全是库卡机器人，且在大小调试后往往都会保留机器人的备份程序。

在工业机器人项目现场，程序阅读并不是孤立的技术行为，而是与调试、维护、工艺验证和知识交接紧密相关的工程活动。对于一条已经投产的焊装或总装线体而言，每次新车型导入、老车型改造、节拍优化或工艺复核，都会牵涉程序调用关系的重新确认。若无法快速回答“当前车型会走哪些程序”“某个轨迹程序被哪些上层逻辑引用”“某台机器人为何会进入某个程序分支”等问题，现场调试和问题定位就只能退回到低效率的人工阅读状态。

在实际产线中，这种人工方式存在三个明显问题。第一，程序数量庞大。一个机器人备份中往往同时包含系统文件、模板文件、工艺程序、车型分支程序和轨迹程序，真正与业务相关的内容混杂在大量文件之中。第二，调用关系层级较深。从 Cell 程序到 P 程序，再到车型码、车型程序、轨迹程序，调用链并不是平铺展开的，而是存在明显层级。第三，程序解释高度依赖经验。熟悉项目历史的人员能够较快读懂某段程序，但这种能力难以沉淀，也难以在人员流动后保持稳定。

与此相对，KUKA 机器人备份文件本身却提供了一个非常有利的基础条件：程序以文本形式保存，并且在标准化调试逐步推进后，命名方式、程序分层和调用模式也逐渐趋于稳定。这使得“通过程序文本自动恢复车型调用关系”成为一个现实可行的方向。也就是说，问题并不是“程序完全无法分析”，而是“现场长期缺乏一套把语言分析能力转化为实用工具的工程化实现”。本文所介绍的程序，正是在这一背景下被开发出来的。

图片标题：图 1 系统总体流程图（zip 输入到结果输出）

图片内容描述： 图中从“机器人备份 zip 文件”开始，依次经过“文件读取与筛选”“模块耦合”“语法解析”“调用关系抽取”“配置过滤”“前端图谱展示”和“Excel 导出”几个阶段，突出程序是一个从备份输入到双结果输出的完整链路。

2. 程序目标

• 结合目前生产线的特点，确定了所开发程序的目标是自动解析机器人备份文件并输出结构化的车型调用关系。
• 说明该系统对调试效率、维护效率、工艺分析和项目交接的价值。
• 交代程序输出既包括网页版可交互的图形化结果，也包括可下载与分享的 Excel 表格。

2.1 目标定义

本程序的直接目标，是将 KUKA 机器人备份中的程序文件自动转化为结构化的车型调用关系结果。这里的“结构化”有两层含义：一是后端能够以统一的数据对象描述不同层级的调用节点及其关系，二是前端和导出模块能够稳定消费这些结构化数据，分别生成可交互的图谱结果和可保存的 Excel 结果。

与第一篇报告中所讨论的“系统性分析 KRL 程序”相比，本文对应的工程实现并没有试图一次性覆盖所有程序语义，而是围绕“调用关系”这一业务目标进行聚焦。也就是说，本系统的首要任务不是解释每一条赋值语句、运动指令或信号联动的完整语义，而是识别哪些程序之间存在稳定的调用与分派关系，并把这些关系组织成能够被现场人员直接使用的结果。

2.2 业务价值

这一目标对现场工作具有直接价值。对调试人员而言，调用关系图可以帮助快速定位某个车型从入口到轨迹的完整链条，减少逐层翻程序的时间。对维护人员而言，当轨迹异常或程序改动引发问题时，可先从调用结构确认受影响范围。对工艺分析人员而言，调用关系表有助于比对不同车型共用或独占的程序路径。对项目交接而言，结构化结果比口头说明更容易沉淀和传播。

2.3 输出形式

为了适应不同使用场景，程序设计了两种输出形式。第一种是本地 Web 页面中的交互式结果，用户可以直接在浏览器中查看线体级和车型级调用关系，并通过节点点击、视图切换等方式理解程序结构。第二种是 Excel 文件，用于存档、转发和跨平台查看。前者强调交互性，后者强调持久化和可分享性，两者共同构成系统的最终输出。

表 1 对系统目标与输出形式做了概括。

3. 架构设计及技术选型

• 给出系统从“文件输入”到“调用关系输出”的总体流程。
• 说明系统采用本地 Web 形态的原因，即兼顾桌面软件的易用性与浏览器界面的可视化能力。定性项目是一款通过Antlr4进行词法分析和语法分析，设计相应数据结构进行语义分析和相关AST的构建，依靠SpringBoot进行交互，借助cytoScope和Apache.poi进行图形渲染和Excel表格保存。

• 说明选择 Spring Boot、ANTLR4、Cytoscape、Apache POI 的原因，分析各技术组件在系统中的角色与协作方式，论证这些技术选型在开发效率、稳定性和扩展能力上的合理性。

• 介绍相关数据结构的设计、后端解析核心、Web 交互、导出模块等职责划分。说明 krl-core 负责语言解析与调用关系抽取，krl-web 负责用户交互、结果返回与文件下载。并分析这种架构在可维护性、复用性和扩展性上的优势。

3.1 本地 Web 形态的选择

本项目最终选择本地 Web 软件而不是传统命令行工具或纯桌面客户端，原因在于它能够兼顾两类优势。一方面，本地启动的形式对现场用户较友好，不需要额外搭建复杂服务环境，只要启动程序并打开浏览器即可使用。另一方面，浏览器界面天然适合呈现图结构、面板交互和表格导出，这使得“调用关系”这一原本较抽象的程序结构能够被直观展示。

在架构上，系统仍然延续第一篇报告所建立的语言分析基础，但在工程落地时重点围绕调用关系这一主线组织模块，不把所有可能的程序语义都放在同一优先级上。这种处理方式使整体实现既能保持理论上的完整来源，又能把开发力量集中在对业务最有价值的部分。

3.2 分层结构

项目被划分为 krl-core 与 krl-web 两个主要模块。krl-core 承担后端的解析内核，包括文件读取、配置加载、模块耦合、ANTLR4 语法分析、调用关系抽取与 Excel 导出。krl-web 承担用户交互入口，包括配置管理、文件上传、同步分析接口、Excel 下载接口以及前端静态页面。这样的分层不是简单按目录拆分，而是把“语言分析能力”和“交互呈现能力”明确隔离。

这种结构有三个直接好处。第一，解析能力可以被单独维护，不会因为界面变化而频繁改动核心逻辑。第二，前端与控制器只面对结构化结果，无需理解语言细节。第三，导出、过滤、可视化等外围能力都能围绕统一的数据结构复用同一套分析结果。

图片标题：图 2 项目分层结构图（krl-core 与 krl-web）

图片内容描述： 图中上层为本地 Web 用户界面，下层为 krl-web 接口与配置管理，再下层为 krl-core 的文件读取、模块装配、语法分析、调用关系抽取与 Excel 导出模块，突出“核心解析能力”与“交互层”的分工。

3.3 技术选型说明

从工程实现看，系统主要依赖四类技术：ANTLR4、Spring Boot、Cytoscape 和 Apache POI。

ANTLR4 的作用是把第一篇报告中的 krl.g4 文法落地为可执行的分析器，使系统具备稳定的词法分析和语法分析能力。Spring Boot 的作用是为本地 Web 形态提供统一入口，便于处理文件上传、配置读取和结果返回。Cytoscape 的作用是把调用关系渲染为交互式拓扑图，帮助用户从结构上理解程序。Apache POI 的作用是将结果导出为标准 Excel 文件，满足结果持久化和分享需求。

表 2 总结了主要技术组件及其职责。

4. 机器人备份文件读取流程设计

• 说明输入对象为 KUKA 机器人备份 zip 文件。
• 介绍解压、遍历、筛选关键文件的流程，以及如何从备份中提取用于分析的源文件和配置信息。
• 说明读取阶段如何识别机器人信息、程序文件和辅助资源。

4.1 输入对象的特点

系统的输入对象是 KUKA 机器人备份 zip 文件。与普通压缩包不同，这类备份并不是为人类直接阅读准备的文档集合，而是控制器文件系统在某一时间点的镜像。程序分析要想建立在真实项目数据之上，就必须先解决“如何以尽可能低损耗的方式读取压缩包内容”的问题。

4.2 文件读取主链

这一阶段的核心类是 KrlZipLoader。它并不只是简单地解压所有文件，而是通过 NIO 文件系统接口把 zip 当作一个可遍历的虚拟文件系统来处理。这样设计的好处是，程序可以保留备份中的原始路径结构，而不是在解压后再依赖额外规则恢复层级关系。对于 KRL 分析来说，文件路径本身就包含模块组织信息，因此保留路径比单纯拿到文件内容更重要。

在遍历过程中，系统会按配置规则筛选真正需要的文件。被保留下来的文件会进一步读取文本内容、创建时间、修改时间、文件大小、文件后缀和所属目录等信息，并封装为 KrlFile 对象。这样做的目的，是在分析开始之前就把“文件内容”和“文件上下文”统一保存下来。

4.3 KrlFile 的设计思路

KrlFile 是读取阶段最基础的数据结构之一。它保存的并不只是程序文本，还包括原始路径、文件名、所属目录、创建时间、修改时间、文件大小、扩展名以及文件类型。之所以要保留这些字段，是因为后续分析并不是只依赖文本本身。例如，是否属于系统目录、文件名是否与模块名一致、文件时间是否可用于人工辅助判断，都与这些信息有关。

4.4 读取阶段的输出

读取阶段的直接输出并不是调用关系，而是一组可供后续装配的文件对象集合。此时系统已经知道“有哪些候选文件值得分析”，但还不知道它们在语言层和业务层中的角色。也正因为如此，读取阶段被单独设计为一层独立能力，而不是直接把压缩包内容塞给解析器。

5. .dat 与 .src 模块耦合策略

• 说明 KRL 程序在工程上通常由数据文件和源码文件组成，单独分析任一文件都不完整。
• 介绍系统如何按照模块名、路径及文件类型将 .dat、.src 耦合成统一模块。
• 说明这种模块化组织的必要性和重要性以及如何为后续语法分析和调用关系提取提供基础数据单元。

5.1 从文件到模块的必要性

KRL 的文件组织方式决定了“文件”并不是最合适的分析粒度。通常情况下，一个模块由同名的 .src 与 .dat 文件共同组成：前者承载程序主体，后者承载变量、结构体、枚举或模块数据。若只从文件层面处理，后续分析很容易出现信息割裂，例如过程定义出现在 .src 中，而相关声明或数据又出现在 .dat 中。

5.2 KrlModule 与仓库结构

为了解决这一问题，系统在 KrlFile 之上引入了 KrlModule。KrlModule 以模块名为中心，同时持有对应的 .src 文件和 .dat 文件，并把它们看作同一分析单元。与之配套的是 ModuleRepository。该类一方面维护“模块名 -> 模块”的主索引，另一方面维护“可调用程序名 -> 所在模块”的反向索引，从而为后续根据程序名回溯所属模块提供支持。

这种设计的价值在于，它把“压缩包里分散的文件集合”整理成了“可面向语言结构分析的模块集合”。这样，后续的解析器不需要再关心文件是从哪里来的，而只需要面对一个相对稳定的模块输入。

5.3 模块耦合的工程约束

模块耦合并不是任意拼接，而是建立在工程约束之上的。系统默认模块名与文件名一致，且一个模块最多只有一个 .src 和一个 .dat。这类约束与现场实际项目中的命名规范相匹配，也让仓库装配过程更容易发现异常，例如同名文件重复、类型冲突或模块不完整等。

5.4 为什么这一步不能省略

如果直接对所有文件逐个做语法分析，程序当然也能得到某些局部结果，但这些结果很难形成稳定的业务语义。原因在于，KRL 的很多结构只有放到“模块”这一层级上才能被正确理解。模块耦合实际上起到了承上启下的作用：向上承接文件读取结果，向下为语法分析和调用关系识别提供统一输入。

6. 调用关系解析流程设计

• 介绍从模块中提取 Cell 程序、P 程序、车型代码、车型程序与轨迹程序的过程。
• 说明调用关系图的数据结构设计，包括节点类型、节点属性和边关系。
• 解释如何从解析结果映射为前端可消费的 JSON 数据。

6.1 从文法分析到业务结构识别

这一阶段是全系统的核心。第一篇报告已经说明了如何通过 krl.g4 识别 KRL 的语言结构；在工程实现中，这一能力首先由 ModuleParser 承接。该类会使用 ANTLR4 生成的 krlLexer 与 krlParser 对 KrlModule 进行解析，并借助访问器把解析树转换为更适合业务处理的结构化结果。

但本系统并不在这一层停留。仅仅知道某个模块中存在哪些过程、表达式或语句，还不足以直接满足现场用户的需求。真正有价值的是把这些语言结构进一步映射到业务中的调用层次。因此，后续由 CarCallReferenceAnalyze 在模块集合上继续执行业务规则判断，最终恢复出车型调用链条。

6.2 调用层次的恢复路径

在当前项目中，核心恢复路径可以概括为：先从 cell.src 一类入口程序中识别 P 程序的调用；再从 P 程序中识别车型代码与车型程序的分派；再从车型程序中识别实际的轨迹程序调用。这个过程并不只是“看谁调用了谁”，而是结合 KRL 代码中常见的 SWITCH/CASE、程序号、车型码和业务命名习惯，把原始程序结构映射为更贴近现场理解方式的层级关系。

6.3 调用图数据结构

为了承接这一结果，系统设计了统一的调用图节点结构 CallNode。每个节点至少包含以下信息：

• 节点唯一标识 id
• 展示值 value
• 节点类型 nodeType
• 相关文本信息 relevantInfo
• 子节点集合 children
• 辅助属性集合 propertyMap

在此基础上，NodeType 进一步标识节点角色，例如 CEll、P_PROGRAM、VIRTUAL、CAR_CODE、CAR_PROGRAM、ROUTE_PROCESS。这种设计有两个明显好处。第一，前端不需要理解后端所有解析细节，只要根据统一节点结构渲染即可。第二，Excel 导出模块也可以复用同一份节点数据，不必重新做一套结构转换。

6.4 RobotInfo 的角色

在调用图之外，最终结果还需要保留机器人自身的信息。RobotInfo 因此被设计为结果对象的根层封装，它既包含 robotName、archiveName、archiveDate、version、techPackList 等元信息，也包含 callGraphRoot 这一调用图根节点。这样设计之后，一次分析返回的结果就不只是“若干节点”，而是一组以机器人为单位组织好的完整结果对象。

6.5 面向前端 JSON 的映射

由于 RobotInfo 与 CallNode 本身就是树形结构友好的对象，后端在同步分析完成后几乎可以直接将其序列化为 JSON 返回给前端。也就是说，前端接收到的并不是一份重新包装过的展示专用数据，而是与后端核心分析结果高度一致的结构化对象。这种做法减少了数据二次转换的复杂度，也降低了前后端结构不一致的风险。

表 3 总结了几类关键数据结构及其作用。

7. Config 配置驱动的噪音过滤机制

• 说明工业机器人程序中存在大量基础模块、系统模块和业务无关调用，若不加筛选会干扰分析结果。
• 介绍 Config.yml 在过滤前缀、后缀、目标模块、忽略规则等方面的作用。介绍他的运行方式: resource代码中有最初内容、config.yml文件进行持久化配置，网页中也可临时修改用于当前分析。
• 说明配置驱动方式如何兼顾通用性与项目定制化需求。

7.1 为什么必须做过滤

工业机器人备份中的程序并不全部服务于车型调用分析。系统模块、基础模板、公共子程序、工艺无关例程和某些调试辅助文件如果全部纳入结果，会导致调用图被大量噪音淹没，反而降低工具的可用性。因此，语言上“能识别”并不意味着业务上“都应展示”。

7.2 Config.yml 的作用

为了把语言识别能力转化为业务可用结果，系统引入了 Config.yml。在结构上，配置文件并不是一组零散开关，而是围绕几类核心问题组织的：哪些路径需要读取，哪些模块或前后缀需要忽略，哪些程序属于重点分析范围，哪些规则用于在噪音与有效调用之间做裁剪。

在实现上，YamlConfigLoad 负责把 YAML 文本解析为 Config 对象，而 IgnoreRuleByStr 则负责将配置中的前缀、后缀与目标匹配规则真正应用到文件和程序筛选过程中。这种方式让过滤逻辑从代码中解耦出来，避免不同项目只能通过改源码来适配现场差异。

7.3 三层配置来源

在本地 Web 软件中，配置一共存在三层来源。第一层是 krl-core 资源目录中的默认配置，作为程序初始模板。第二层是磁盘上的 Config.yml，由 ConfigStorageService 在程序启动时初始化并持续保留，适合存放长期有效的规则。第三层是页面中的临时配置文本，用户可以通过 Config 按钮打开编辑器，仅对当前这次分析进行覆盖。这种设计既保证了开箱即用，也允许按现场实际情况灵活调整。

7.4 配置驱动的价值

从工程角度看，配置驱动带来的最大好处不是“参数更多”，而是“适配成本更低”。调用关系分析的核心程序无需频繁改动，只需要根据不同项目、不同线体、不同命名习惯调整规则，就能得到更加贴近现场需要的结果。这使系统具备了较好的通用性与项目定制能力。

8. 本地 Web 交互设计

• 说明使用 Spring Boot 构建本地 Web 软件的原因，包括启动便捷、接口清晰、静态资源集成方便。
• 介绍用户操作流程：上传备份、读取配置、执行分析、查看结果、下载 Excel。

8.1 为什么使用 Spring Boot 承载本地 Web 交互

虽然系统的核心价值在于 KRL 解析，但若没有一个友好的交互外壳，解析结果就很难被现场用户充分利用。Spring Boot 在这里的角色并不是复杂业务平台，而是一个轻量、明确的本地接口与页面承载框架。它能够同时处理文件上传、配置读取、静态页面发布和结果下载，使本地程序具备类似网页应用的使用体验。

8.2 控制器与执行服务分层

在本地模式下，前端主要通过三个接口与后端交互：/api/config、/api/analysis 和 /api/analysis/excel。其中，AnalysisController 负责参数接收和 HTTP 响应封装，而真正的同步分析流程由 AnalysisExecutionService 执行。这样的分层有助于控制器保持简洁，把文件校验、临时目录创建、上传文件落盘、调用核心分析服务和 Excel 导出等流程集中放到服务层处理。

8.3 用户交互流程

用户打开程序后，首先可以读取当前磁盘上的配置，并在页面中查看或临时编辑。随后通过上传按钮选择一个或多个机器人备份 zip 文件。点击“开始分析”后，前端会把上传文件和当前配置文本以表单方式提交给 /api/analysis，后端返回 RobotInfo 列表。若用户需要保存结果，则可点击“下载 Excel”，由前端将相同输入提交给 /api/analysis/excel 并直接获取二进制文件。

图片标题：图 3 本地 Web 用户操作流程图

图片内容描述： 图中展示用户从“打开程序”开始，依次执行“读取配置”“上传备份”“开始分析”“查看图谱结果”“下载 Excel”的流程，突出本地 Web 交互的线性操作路径。

8.4 页面结构组织

前端页面由品牌区、顶部工具区、调用图画布、信息面板、视图切换器、节点控制区和 Config 编辑弹窗组成。其核心设计思路是：把高频操作集中在顶部，把结果呈现在中央画布，把辅助信息放在侧边或弹窗中，从而形成清晰的主次层次。这样既保留了网页操作的直观性，也兼顾了本地桌面使用时的效率。

9. 调用关系图可视化设计

• 介绍为何采用图结构展示调用关系，以及图形化结果在理解程序拓扑时的优势。
• 说明 Cytoscape 在节点布局、类型样式、交互切换和层级展示中的具体作用。
• 介绍线体信息视图与车型信息视图的设计思路。
• 介绍最终效果，如"可以高亮查看调用链条和被调用链"。

9.1 为什么要使用图结构

调用关系天然是图结构而不是普通表格结构。一个上层程序可能分派到多个车型分支，一个车型程序又可能调用多个轨迹程序，单纯用列表很难直观表达这种“多层连接”的关系。因此，图谱展示是理解程序拓扑最自然的方式。

9.2 Cytoscape 的角色

Cytoscape 负责把后端返回的调用节点组织为可交互的图。前端会根据 NodeType 为不同节点赋予不同样式，例如颜色、形状、边框和尺寸，并结合布局算法把同层级节点尽可能稳定地分布在合理位置。用户不仅可以看到整体结构，还可以点击节点查看详情，并在视图中高亮相关调用链条，从而快速理解上游和下游关系。

9.3 两类核心视图

当前页面主要提供两类视图。第一类是“线体信息”视图，它把每一个机器人备份作为一个根节点，用于帮助用户先在整条线体中定位目标机器人。第二类是“车型信息”视图，它会展开某一机器人内部的程序调用层级，让用户进一步观察 Cell、P 程序、车型码、车型程序和轨迹程序之间的关系。这样的双视图设计，可以把“先看整体，再钻取细节”的使用习惯自然落实到界面上。

9.4 信息侧栏与节点控制

除了纯粹的图谱展示，前端还提供了信息面板和节点控制面板。信息面板用于显示机器人元信息、节点路径、时间和相关文本内容，帮助用户把抽象节点与实际程序文件对应起来。节点控制面板则允许按节点类型高亮或调整尺寸，使不同层级的结构差异更加清晰。

10. Excel 导出方案设计

• 说明在线图谱虽然直观，但在存档、转发、跨平台查看方面存在局限。
• 介绍使用 Apache POI 生成 Excel 的原因及导出目标。
• 说明 Excel表相比在线图谱，无法直接表示"图"这种数据结构信息，难以醒目体现调用链和被调用链。于是有了Excel表格中树形结构区、调用矩阵区、颜色映射和层级表达的设计思路。

10.1 为什么还需要 Excel

网页图谱适合交互式查看，但在存档、汇报、跨部门转发和离线阅读场景中，Excel 更符合多数用户的使用习惯。因此，系统在设计之初就没有把在线图谱视为唯一输出，而是把 Excel 看作同等重要的结果载体。

10.2 独立导出服务的必要性

Excel 导出由 CallGraphExcelExportService 独立承担，而没有直接写进控制器。这样做是因为导出逻辑本身就足够复杂：它不仅要遍历调用图，还要设计 Sheet 命名、单元格样式、列宽、合并关系、颜色区分和矩阵映射。把这部分逻辑独立出来，能够让控制器与分析服务继续保持单一职责。

10.3 树形区与调用矩阵区

由于 Excel 本身不是图结构工具，直接把调用图“原样”搬进去并不可行。为了解决这一问题，导出方案采用了两部分结构。上半部分是树形结构区，按 Cell 程序 -> P 程序 -> 车型代码 -> 车型程序 -> 轨迹程序 的列层级展开调用路径，并通过合并单元格减少重复。下半部分是调用矩阵区，横向表示调用方，纵向表示被调用方，用于突出直接调用关系。前者便于顺着层级阅读，后者便于整体观察连接模式，两者结合后能够较好弥补 Excel 不擅长表达图结构的问题。

10.4 每机器人一 Sheet 的组织方式

系统将每个机器人结果导出到一个独立 Sheet 中，而不是把所有机器人堆在同一张表里。这是因为机器人之间的程序集合、车型数量和轨迹规模都可能不同，若混在一起会明显降低可读性。以机器人为单位划分 Sheet，既符合前端线体视图的组织方式，也方便结果存档与人工核对。

图片标题：图 4 调用关系图与 Excel 双输出示意图

图片内容描述： 图中左侧为网页中的调用关系图，右侧为 Excel 中的树形区与调用矩阵区，强调二者虽然展示形式不同，但都来自同一份结构化结果数据。

11. 程序整体流程说明

• 介绍包结构、核心类职责划分和模块边界设计。说明为什么要将语言解析能力与 Web 交互能力解耦。
• 按时间顺序介绍主要实现过程：读取 zip、构建模块、执行语法分析、抽取调用关系、按配置过滤、生成 JSON、前端渲染、导出 Excel。
• 说明各阶段的数据输入输出关系，形成完整的工程闭环。
• 分析配置管理、异常处理、日志记录和导出服务在工程中的组织方式。

11.1 主要模块及职责划分

从代码组织角度看，系统的大部分职责都可以落到几条主链上：loader 负责读取输入，parser 负责模块装配与程序分析，service 负责调用关系抽取和 Excel 导出，pojo 负责承载中间与最终数据结构，krl-web 则负责把核心能力转换为可操作的本地 Web 接口和页面。这种划分方式让系统形成了较清晰的工程边界。

表 4 概括了主要模块及其职责。

11.2 输入到输出的完整链路

从时间顺序上看，程序运行过程可以描述为以下几个步骤：

1. 用户上传一个或多个机器人备份 zip 文件。
2. 后端将上传文件保存到临时目录，并根据当前配置读取文件内容。
3. KrlZipLoader 遍历压缩包，筛选有效文件并生成 KrlFile 列表。
4. ModuleRepository 按模块名耦合 .src 与 .dat，形成 KrlModule 集合。
5. ModuleParser 调用 ANTLR4 生成的分析器，对模块进行语法解析。
6. CarCallReferenceAnalyze 根据程序结构恢复车型调用关系。
7. CarCallAnalysisService 结合 am.ini 等信息补充机器人元数据，生成 RobotInfo 列表。
8. 若是网页查看，则结果被序列化为 JSON 返回前端并由 Cytoscape 渲染。
9. 若是 Excel 导出，则结构化结果被送入 CallGraphExcelExportService 生成工作簿字节流。

这一链路的关键特点在于，各阶段输入输出边界清晰。文件读取阶段输出 KrlFile，模块装配阶段输出 KrlModule，调用关系分析阶段输出 RobotInfo 与 CallNode，前端和导出阶段都以同一结构化结果为输入。这样既避免了重复转换，也使系统更容易定位问题。

11.3 配置、异常与日志在工程中的位置

配置管理、异常处理和日志记录并不直接产生调用关系，但它们决定了程序是否真正可用。配置管理保证系统能够在不同项目间快速调整规则。异常处理保证上传错误、配置错误、解析错误和导出错误能够被明确识别，而不是以模糊失败形式呈现。日志记录则帮助开发和维护人员追踪分析流程，理解每一步的输入输出规模和失败位置。对于一款面向实际生产支持的软件而言，这些看似“外围”的工程能力同样是完整实现的一部分。

12. 总结

• 总结本文的工程设计方法与实际实现成果。
• 总结程序在降低人工分析成本、提升问题定位效率、辅助知识沉淀方面的作用。

本文在第一篇 KRL 文法分析研究的理论基础上，围绕车型调用关系这一明确目标，完成了一套本地 Web 软件的工程实现说明。从机器人备份文件读取，到 .src 与 .dat 的模块耦合，再到 ANTLR4 语法分析、调用关系抽取、配置过滤、图谱展示和 Excel 导出，系统建立了一条从原始备份到可读结果的完整处理链。

从工程方法上看，本文的核心不是简单堆叠技术组件，而是把不同层次的问题分别交给合适的模块处理：文件层解决输入组织问题，模块层解决程序归属问题，语法层解决结构识别问题，业务层解决调用关系恢复问题，交互层解决结果表达问题。这种分层使系统既具备可维护性，也具备后续扩展空间。

从实际价值上看，该程序能够显著降低人工分析机器人程序的重复劳动，帮助调试人员和维护人员更快定位车型调用链，辅助工艺问题排查，并为项目交接与知识沉淀提供更加稳定的载体。对于一项直接服务现场的工程工具而言，能够把复杂程序结构转化为用户易于理解和传播的结果，本身就是其最重要的成果。

参考资料

• 项目代码：/Users/liuke/IdeaProjects/KRLParser/krl-core
• 项目代码：/Users/liuke/IdeaProjects/KRLParser/krl-web
• KRL 文法文件：/Users/liuke/IdeaProjects/KRLParser/krl-core/src/main/resources/krl.g4
• 关键实现类：/Users/liuke/IdeaProjects/KRLParser/krl-core/src/main/java/tech/waitforu/loader/KrlZipLoader.java
• 关键实现类：/Users/liuke/IdeaProjects/KRLParser/krl-core/src/main/java/tech/waitforu/parser/ModuleRepository.java
• 关键实现类：/Users/liuke/IdeaProjects/KRLParser/krl-core/src/main/java/tech/waitforu/parser/CarCallReferenceAnalyze.java
• 关键实现类：/Users/liuke/IdeaProjects/KRLParser/krl-web/src/main/java/tech/waitforu/krlweb/controller/AnalysisController.java