代码静态检测方法、工具、装置、存储介质及设备

技术领域

本公开属于工业控制技术领域，特别涉及一种代码静态检测方法、工具、装置、存储介质及设备。

背景技术

PLC（Programmable Logic Controller，可编程控制器）广泛应用于工控行业设备监控、运行控制等场景，PLC程序运行问题会导致巨大的经济损失，引发严重后果，因此对PLC程序的稳定性、可靠性有较高要求。目前，PLC程序IO点数不断增大，PLC程序状态空间指数级增加，使得通过构造测试集结合仿真、调试等方式验证程序逻辑、定位问题难以实现状态集有效覆盖，效果差，效率低。

类似C语言等高级语言具有完善的代码静态检测机制，可作为动态检测技术的有效补充，以更高效的方式实现有效的缺陷检测，而PLC行业静态检测技术却乏善可陈。

发明内容

基于上述问题，本公开能够针对目前PLC组态软件调测工具存在的问题，从风电、水电等工控行业应用实际调测存在的问题和痛点出发，提供一种可集成到自研PLC组态软件亦可独立运行的PLC代码静态检测工具、实现可编程控制器代码静态检测的方法、装置、存储介质及设备。

为了达到上述目的，根据本公开实施例的第一方面，提供一种代码静态检测方法，应用于可编程控制器，所述方法包括：

设置所述可编程控制器代码的静态分析参数；

将所述可编程控制器代码传递到检测工具进行基于所述静态分析参数的分析检测；

依据不同的交互方式输出分析检测结果。

可选地，所述设置所述可编程控制器代码的静态分析参数包括：

设置启用的分析检测规则、所述分析检测结果的输出路径以及目标可编程控制器的设备参数。

可选地，所述将所述可编程控制器代码传递到检测工具进行基于所述静态分析参数的分析检测包括：

构造抽象语法树；

基于所述抽象语法树构建控制流图；

根据所述抽象语法树和所述控制流图遍历执行所述分析检测规则，并保存分析检测结果。

可选地，所述构造抽象语法树包括：

将所述可编程控制器代码统一转换为结构化文本语言程序；

基于所述结构化文本语言程序构造抽象语法树。

可选地，所述基于所述抽象语法树构建控制流图包括：

将所述抽象语法树转换为静态单赋值形式的中间代码；

基于所述中间代码构建控制流图。

可选地，在构造抽象语法树之前，所述将所述可编程控制器代码传递到检测工具进行基于所述静态分析参数的分析检测还包括：

根据不同的交互方式将所述可编程控制器代码传递到所述检测工具；

对所述可编程控制器代码进行代码解析。

可选地，所述根据所述抽象语法树和所述控制流图遍历执行所述分析检测规则，并保存分析检测结果包括：

按照所述静态分析参数依次调度各分析检测规则对应的规则执行引擎进行分析检测；

所述规则执行引擎根据检测目标选择不同的检测算法进行分析检测，并保存分析检测结果。

可选地，所述分析检测规则包括：

通用缺陷检测规则和特定行业缺陷检测规则。

可选地，所述依据不同的交互方式输出分析检测结果包括：

通过应用程序编程接口API（Application Programming Interface）交互时，通过API接口输出分析检测进度及所述分析检测结果；

通过文件交互时，将所述分析检测进度及所述分析检测结果写入输出文件中。

根据本公开实施例的第二方面提供一种代码静态检测工具，应用于可编程控制器，所述工具包括：交互层、处理层和支撑层；

所述交互层用于与外部进行数据交互；

所述处理层用于代码分析检测处理；

所述支撑层用于提供代码分析检测规则和规则执行引擎支撑。

可选地，所述交互层包括交互处理器、文件交互适配器以及API交互适配器；

所述交互处理器用于以统一的格式实现外部与内部的数据交互处理；

所述文件交互适配器用于在所述交互处理器的基础上实现以文件方式与外部进行数据交互；

所述API交互适配器用于在所述交互处理器的基础上实现以API方式与外部进行数据交互。

可选地，所述处理层包括解析器、转换器、词法分析器、语法分析器、构造器和调度器；

所述解析器用于接收由所述交互处理器传递的待分析代码，并按照TC6标准（Technical Committee 6，由PLCOpen（Programmable Logic Controller Open，致力于推广IEC61131-3标准的全球性协会）技术委员会制定的用于存储PLC程序的Xml格式的标准）进行格式验证、数据解析；

所述转换器用于实现所述待分析代码中多语言到结构化文本语言的转换；

所述词法分析器用于从所述结构化文本语言的代码中分析识别出词法序列，同时填充程序符号表；

所述语法分析器用于根据所述词法序列构造出抽象语法树，并填充所述程序符号表；

所述构造器用于在所述抽象语法树以及所述符号表的基础上先生成静态单赋值形式的中间代码，再对所述中间代码执行控制流分析构造出控制流图；

所述调度器用于负责整个分析检测过程中的功能调度及规则引擎的运行调度。

可选地，所述支撑层包括：

存储静态分析参数的分析配置文件、存储分析检测规则数据的规则库及一系列执行实际分析检测的规则执行引擎。

根据本公开实施例的第三方面提供一种代码静态检测装置，应用于可编程控制器，所述检测装置包括：

设置模块，用于设置所述可编程控制器代码的静态分析参数；

分析检测模块，用于将所述可编程控制器代码传递到检测工具进行基于所述静态分析参数的分析检测；

输出模块，用于依据不同的交互方式输出分析检测结果。

根据本公开实施例的第四方面提供一种非临时性计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现第一方面中任一项所述方法的步骤。

根据本公开实施例的第五方面提供一种电子设备，包括：

存储器，其上存储有计算机程序；

处理器，用于执行所述存储器中的所述计算机程序，以实现第一方面中任一项所述方法的步骤。

综上所述，本公开实施例提供一种代码静态检测方法，应用于可编程控制器，所述方法包括：设置所述可编程控制器代码的静态分析参数；将所述可编程控制器代码传递到检测工具进行基于所述静态分析参数的分析检测；依据不同的交互方式输出分析检测结果。本公开实施例能够对工控行业代码进行静态检测，相比于动态检测技术具有执行速度快、效率高、代价小的优势，此外还能处理特定行业应用程序代码的非逻辑性缺陷。

附图说明

为了更清楚地说明本公开的实施方案，下面将对实施方式中所需要使用的附图作简单地介绍，应当理解，附图仅示出了本公开的某些实施方式，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据附图获得其他相关的附图。

图1是根据一示例性实施例示出的一种代码静态检测方法流程图；

图2是根据一示例性实施例示出的一种代码静态检测方法流程图；

图3是根据一示例性实施例示出的一种代码静态检测方法流程图；

图4是根据一示例性实施例示出的一种代码静态检测方法流程图；

图5是根据一示例性实施例示出的一种代码静态检测方法流程图；

图6是根据一示例性实施例示出的一种代码静态检测方法流程图；

图7是根据一示例性实施例示出的一种代码静态检测方法流程图；

图8是根据一示例性实施例示出的一种代码静态检测方法流程图；

图9是根据一示例性实施例示出的一种代码静态检测工具的控制流图；

图10是根据一示例性实施例示出的一种代码静态检测工具的架构示意图；

图11是根据一示例性实施例示出的一种代码静态检测工具的数据流图；

图12是根据一示例性实施例示出的一种代码静态检测装置1200的框图；

图13是根据一示例性实施例示出的一种电子设备1300的框图。

具体实施方式

为能清楚说明本方案的技术特点，下面通过具体实施方式并结合附图，对本公开进行详细阐述。

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

应当理解，本公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本公开的范围在此方面不受限制。

本文使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。

需要注意，本公开中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。在本公开的描述中，除非另有说明，“多个”是指两个或多于两个，其它量词与之类似；“至少一项（个）”、“一项（个）或多项（个）”或其类似表达，是指的这些项（个）中的任意组合，包括单项（个）或复数项（个）的任意组合。例如，至少一项（个）a，可以表示任意数目个 a；再例如，a，b和 c 中的一项（个）或多项（个），可以表示：a，b，c，a-b，a-c，b-c，或 a-b-c，其中 a，b，c 可以是单个，也可以是多个；“和/或”是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A 和/或 B，可以表示：单独存在 A，同时存在 A 和 B，单独存在 B 这三种情况，其中 A，B 可以是单数或者复数。

在本公开实施例中尽管在附图中以特定的顺序描述操作或步骤，但是不应将其理解为要求按照所示的特定顺序或是串行顺序来执行这些操作或步骤，或是要求执行全部所示的操作或步骤以得到期望的结果。在本公开的实施例中，可以串行执行这些操作或步骤；也可以并行执行这些操作或步骤；也可以执行这些操作或步骤中的一部分。

同时，可以理解的是，本技术方案所涉及的数据（包括但不限于数据本身、数据的获取或使用）应当遵循相应法律法规及相关规定的要求。下面结合具体实施例对本公开进行说明。

首先，对本公开的应用场景进行说明。目前仿真、在线观测、监视、调试是PLC组态软件进行功能验证和故障定位的主流技术。其基本原理是构造输入数据集，让程序在软件模拟环境或实际硬件环境自动化或在受控模式下运行，通过观察、检测运行状态或变量值判断程序执行状态或定位问题原因。实际工控场景中、大型PLC居多，IO数量在100+，且呈现出逐渐增多的趋势，因此程序IO组合状态空间很大。调测时所设计的用例只能覆盖极小部分的实际运行IO组合状态，因此针对特定IO组合下存在的问题不一定能定位到。

此外对于偶发性问题或在特定上下文才发生的问题未必能重现也无从定位原因。无论使用上述哪种方式检测问题都要求执行者熟悉程序运行逻辑，对于逻辑较复杂的程序，梳理清楚程序逻辑本身就是一件费时费力的事情。

已公开的PLC组态软件未提供针对混合使用IEC61131-3（InternationalElectrotechnical Commission 61131-3，国际电工委员会制定的可编程逻辑控制器标准的第3部分：编程语言）标准开发语言情景下代码静态检测功能，程序缺陷只能通过仿真、测试、调试等动态方式进行检测、定位，存在工作量大、效率低的问题。

风电、水电等工控行业对PLC扫描周期精度、程序运行稳定性有较高要求，目前对于偶发性扫描周期波动、运行不稳定问题尚未有有效的检测工具，事后排查处理问题效率低，成本高。

针对目前PLC组态软件调测工具存在的问题，本公开从风电、水电等工控行业应用实际调测存在的问题和痛点出发，实现一种可集成到自研PLC组态软件亦可独立运行的PLC代码静态检测工具。该工具综合运用缺陷规则检测、数据流分析和控制流分析技术可在不运行程序的情况下对使用IEC61131-3定义的多种语言混合开发的PLC程序进行代码缺陷分析检测，并输出检测结果及修复建议。可检测的缺陷包括通用缺陷（不良编码风格类缺陷和潜在逻辑类缺陷）、特定行业缺陷。相比于动态检测技术具有执行速度快、效率高、代价小的优势。

图1是根据一示例性实施例示出的一种代码静态检测方法流程图。如图1所示，本公开实施例提供一种代码静态检测方法，应用于可编程控制器，所述方法可以包括如下几个步骤：

在步骤S10中，设置所述可编程控制器代码的静态分析参数。

在此步骤中，启动代码静态分析检测首先需设置静态分析参数，否则将使用默认的分析参数。设置的静态分析参数主要包括启用的分析检测规则、分析结果的输出路径以及目标PLC的设备参数。通过API交互时直接调用对应API即可，通过文件交互时首先将配置参数以json格式保存在文件中，然后将配置文件路径以命令行参数传递至检测工具。设置分析参数后检测工具会将分析参数更新到分析配置文件中。

在步骤S20中，将所述可编程控制器代码传递到检测工具进行基于所述静态分析参数的分析检测。

在此步骤中，检测工具读取分析配置文件中的配置参数，结合规则库计算出本次分析所使用的分析检测规则，遍历执行分析检测规则时，先由分析检测规则生成规则引擎，之后执行规则引擎；规则引擎执行时会综合使用抽象语法树、控制流图，执行规则分析检测逻辑并暂存分析结果。

在步骤S30中，依据不同的交互方式输出分析检测结果。

在此步骤中，检测工具对外提供分析执行进度及分析检测结果，具体方式依据交互方式而定。通过API交互时通过API交互适配器提供的接口供调用方获取分析执行进度及分析检测结果。通过文件交互时，文件交互适配器按照分析参数配置定时将分析进度及分析结果写入输出文件中。

综上所述，本公开实施例提供一种代码静态检测方法，应用于可编程控制器，所述方法包括：设置所述可编程控制器代码的静态分析参数；将所述可编程控制器代码传递到检测工具进行基于所述静态分析参数的分析检测；依据不同的交互方式输出分析检测结果。本公开实施例能够对工控行业代码进行静态检测，相比于动态检测技术具有执行速度快、效率高、代价小的优势。

图2是根据一示例性实施例示出的一种代码静态检测方法流程图。如图2所示，所述设置所述可编程控制器代码的静态分析参数可以包括如下步骤：

在步骤S101中，设置启用的分析检测规则、所述分析检测结果的输出路径以及目标可编程控制器的设备参数。

在此步骤中，设置启用的分析检测规则、所述分析检测结果的输出路径以及目标可编程控制器的设备参数。示例性的，分析检测规则可以分为通用缺陷检测规则、特定行业缺陷检测规则。通用缺陷包括不良编码风格类缺陷和潜在逻辑类缺陷。行业相关缺陷是从风电、水电等工控行业对PLC扫描周期精度、运行稳定性、可靠性的特定行业要求出发，结合实际运行情况归纳出的一些可能影响扫描周期精度、运行稳定性的代码编写模式，例如过多的循环嵌套、间接的递归调用、栈溢出、IO区溢出等。

图3是根据一示例性实施例示出的一种代码静态检测方法流程图。如图3所示，所述将所述可编程控制器代码传递到检测工具进行基于所述静态分析参数的分析检测可以包括如下几个步骤：

在步骤S203中，构造抽象语法树。

在此步骤中，先将待检测目标代码中的多语言代码转换为结构化文本语言，再对结构化文本语言进行词法分析和语法分析，生成抽象语法树。

在步骤S204中，基于所述抽象语法树构建控制流图。

在此步骤中，先将抽象语法树转换为静态单赋值形式的中间代码，之后再基于中间代码构造控制流图。

在步骤S205中，根据所述抽象语法树和所述控制流图遍历执行所述分析检测规则，并保存分析检测结果。

在此步骤中，首先结合分析配置文件及规则库获取所有分析检测规则，之后遍历所有分析检测规则。在处理每个分析检测规则时从规则库获取规则执行引擎信息并加载规则执行引擎，之后执行规则执行引擎的运行方法，启动规则检查，规则执行引擎执行过程中将分析检测结果暂存到内存。

定时轮询规则引擎执行状态，当前规则执行引擎执行完毕后检查是否还存在待执行的规则，如有继续执行，否则结束分析过程，并汇总分析结果。

图4是根据一示例性实施例示出的一种代码静态检测方法流程图。如图4所示，所述构造抽象语法树可以包括如下几个步骤：

在步骤S2031中，将所述可编程控制器代码统一转换为结构化文本语言程序。

在此步骤中，将所述可编程控制器代码统一转换为结构化文本语言程序。示例性的，将待检测目标代码中使用IEC61131-3图形语言，例如：LD（Ladder Diagram，梯形图）、FBD（Function Block Diagram，功能块图）、SFC（Sequential Function Chart，顺序功能图）以及IL（Instruction List，指令表）语言编写的代码转换为ST（Structured Text，结构化文本）语言对应的实现。图形语言转换逻辑是依据IEC61131-3标准中各图形元件的定义，首先将复杂元件拆分为基础元件的组合，然后用ST语言实现各基础元件的等同逻辑，最后将组成复杂组件的基础元件的ST语言表示按照拆分规则逆序组合，最终形成复杂图形元件的ST语言表示。

在步骤S2032中，基于所述结构化文本语言程序构造抽象语法树。

在此步骤中，基于所述结构化文本语言程序构造抽象语法树，示例性的，IL语言转换逻辑是通过词法分析、语法分析构造AST（Abstract Syntax Tree，抽象语法树）及IR（Intermediate Representation，中间代码），并基于IR使用模型驱动的方式生成ST，实现源到源代码转换。

词法分析由词法分析器实现，以转换后的ST语言程序为输入，根据词法规则生成程序的词法序列，同时填充符号表中的符号信息。

语法分析由语法分析器实现，根据语法规则，以词法序列、符号表为输入生成程序的抽象语法树，同时填充符号表中语法信息，例如函数信息、全局变量、数据类型定义等。

图5是根据一示例性实施例示出的一种代码静态检测方法流程图。如图5所示，所述基于所述抽象语法树构建控制流图可以包括如下步骤：

在步骤S2041中，将所述抽象语法树转换为静态单赋值形式的中间代码。

在此步骤中，将抽象语法树转换为静态单赋值形式的中间代码，并基于IR使用模型驱动的方式生成ST，实现源到源代码转换。

在步骤S2042中，基于所述中间代码构建控制流图。

在此步骤中，先将AST转换为静态单赋值形式的IR，之后基于IR构造控制流图CFG。构建CFG是对程序中各个基本程序块之间的控制流建模，CFG是一个有向图G=（n，e），节点n对应于一个基本程序块（具有最大长度的无分支代码序列，始于一个有标号的操作，结束于一个分支、跳转或条件判断操作），边e对应于从块到块的可能的控制转移。抽象语法树及控制流图是各规则检测引擎进行分析的基础，各检测规则按照检测目标可通过模型检测、控制流分析、数据流分析等方法执行静态代码检测。

图6是根据一示例性实施例示出的一种代码静态检测方法流程图。如图6所示，在构造抽象语法树之前，所述将所述可编程控制器代码传递到检测工具进行基于所述静态分析参数的分析检测还可以包括如下步骤：

在步骤S201中，根据不同的交互方式将所述可编程控制器代码传递到所述检测工具。

在此步骤中，将待分析目标代码传递至检测工具。使用API交互时，通过调用API交互适配器接口分批将TC6格式的PLC程序传递至检测工具。使用文件交互时，首先将TC6格式的PLC程序存储到文件，然后将文件路径通过命令行参数传递至检测工具，之后文件交互适配器会处理输入的文件。文件交互适配器、API交互适配器负责实现不同交互方式的输入、输出适配处理，最后将处理后的待分析代码交由交互处理器处理，交互处理器在内存保存待分析的代码。

在步骤S202中，对所述可编程控制器代码进行代码解析。

在此步骤中，对输入的待检测目标代码按照TC6标准进行格式检查、分析，如果解析失败则终止处理，若解析成功则继续执行下一环节。

图7是根据一示例性实施例示出的一种代码静态检测方法流程图。如图7所示，所述根据所述抽象语法树和所述控制流图遍历执行所述分析检测规则，并保存分析检测结果可以包括如下几个步骤：

在步骤S2051中，按照所述静态分析参数依次调度各分析检测规则对应的规则执行引擎进行分析检测。

在此步骤中，按照所述静态分析参数依次调度各分析检测规则对应的规则执行引擎进行分析检测。示例性的，调度器读取分析配置文件中的配置参数，结合规则库计算出本次分析所使用的分析检测规则，遍历执行分析检测规则时，先由分析检测规则生成规则执行引擎，之后执行规则执行引擎进行静态代码检测。

在一些实施例中，所述分析检测规则包括：通用缺陷检测规则和特定行业缺陷检测规则。通用缺陷检测规则包括不良编码风格类缺陷检测规则和潜在逻辑类缺陷检测规则。

对于不良编码风格类缺陷可采用基于AST的模式匹配进行检测。例如针对无default的case规则，在AST上遍历所有的case子树，检测每个case子树上是否存在default子树即可。此类缺陷可通过将不良编码风格调整为建议的编码风格解决。例如针对悬空else问题可给每个if添加else语句解决。

对于潜在逻辑类缺陷，是指一些符合语法、格式良好但由于一些更隐蔽的原因存在潜在风险的缺陷。例如表达式混用多种类型引发的隐式类型变换、不可达代码、布尔算术运算、数组越界、未初始化变量、除零问题、过高的圈复杂度等。此类缺陷相对复杂，但基本上可归类为语义问题、控制流问题或数据流问题，可结合抽象语法树、控制流图，通过缺陷规则分析、控制流分析或数据流分析实现。

特定行业缺陷检测规则是从风电、水电等工控行业对PLC扫描周期精度、运行稳定性、可靠性的特定行业要求出发，结合实际运行情况归纳出的一些可能影响扫描周期精度、运行稳定性的编程模式。例如过多的循环嵌套、间接的递归调用、栈溢出、IO区溢出等。过多的循环嵌套、间接的递归调用会导致PLC扫描周期过长，栈溢出、IO区溢出会导致程序运行崩溃。与通用缺陷相比此类缺陷更加复杂：不存在一致的度量标准、检测复杂度高并且和PLC设备参数关联性较大。针对上述问题，此类检测规则实现可通过参数动态调整检测标准（包含检测基准及PLC设备参数），同时结合抽象语法树、控制流图，通过控制流分析或数据流分析实现。

在步骤S2052中，所述规则执行引擎根据检测目标选择不同的检测算法进行分析检测，并保存分析检测结果。

在此步骤中，规则执行引擎根据检测目标选择不同的检测算法进行分析检测，并保存分析检测结果。示例性的，对于缺陷规则分析来说，隐式类型转换问题，是一个语义问题，其表现为表达式中各变量数据类型不一致或函数实参与形参类型不一致，该问题可通过基于AST的模式匹配方式检测，即遍历AST上存在赋值的子树（赋值语句子树、函数调用子树），结合符号表中的变量类型信息，检查每个赋值语句上所有节点数据类型是否一致或函数参数实参类型与形参类型是否一致来检测。

示例性的，对于控制流分析来说，不可达代码属于控制流问题，不可达代码在CFG上表现为不存在穿越CFG可到达该代码块的代码路径。此问题可在CFG上通过执行标记-清除可达性分析进行检测：首先在每个程序块上初始化一个标记，值为“不可达”，接下来从CFG的入口节点开始，将每个可以到达的CFG节点标记为“可达”，那么最终标记为“不可达”的CFG节点所对应的代码块就是潜在的不可达代码。

示例性的，对于数据流分析来说，未初始化变量是指变量使用前未分配值，该问题检测可在CFG上通过数据流分析实现。首先基于CFG进行局部数据流分析，识别出每个块中的变量声明、变量使用信息；然后遍历每个变量，从CFG起始节点根据块依赖关系进行变量传播，并移除已赋值的变量；最后到达的变量使用块即是未初始化变量的使用处。

上述针对三种典型的分析检测算法进行了示例说明，实际针对每种缺陷，需根据缺陷特征综合考虑具体检测目标及检测算法，以实现快速、高精度静态代码缺陷检测。

图8是根据一示例性实施例示出的一种代码静态检测方法流程图。如图8所示，所述依据不同的交互方式输出分析检测结果可以包括如下几个步骤：

在步骤S301中，通过API交互时，通过API接口输出分析检测进度及所述分析检测结果。

在步骤S302中，通过文件交互时，将所述分析检测进度及所述分析检测结果写入输出文件中。

图9是根据一示例性实施例示出的一种代码静态检测工具的控制流图。关于该代码静态检测工具的控制流程方法步骤，已经在上述有关该方法的实施例中进行了详细描述，详见上述方法步骤的说明。

综上所述，本公开实施例提供一种代码静态检测方法，应用于可编程控制器，所述方法包括：设置所述可编程控制器代码的静态分析参数；将所述可编程控制器代码传递到检测工具进行基于所述静态分析参数的分析检测；依据不同的交互方式输出分析检测结果。本公开实施例能够对工控行业代码进行静态检测，相比于动态检测技术具有执行速度快、效率高、代价小的优势，此外还能处理特定行业应用程序代码的非逻辑性缺陷。

图10是根据一示例性实施例示出的一种代码静态检测工具的架构示意图。如图10所示，本公开实施例提供一种代码静态检测工具，应用于可编程控制器，所述工具包括：交互层、处理层和支撑层；

所述交互层用于与外部进行数据交互；所述处理层用于代码分析检测处理；所述支撑层用于提供代码分析检测规则和规则执行引擎支撑。

在一些实施例中，所述交互层包括交互处理器、文件交互适配器以及API交互适配器；所述交互处理器用于以统一的格式实现外部与内部的数据交互处理；所述文件交互适配器用于在所述交互处理器的基础上实现以文件方式与外部进行数据交互；所述API交互适配器用于在所述交互处理器的基础上实现以API方式与外部进行数据交互。

在一些实施例中，所述处理层包括解析器、转换器、词法分析器、语法分析器、构造器和调度器；所述解析器用于接收由所述交互处理器传递的待分析代码，并按照TC6标准进行格式验证、数据解析；所述转换器用于实现所述待分析代码中多语言到结构化文本语言的转换；所述词法分析器用于从所述结构化文本语言的代码中分析识别出词法序列，同时填充程序符号表；所述语法分析器用于根据所述词法序列构造出抽象语法树，并填充所述程序符号表；所述构造器用于在所述抽象语法树以及所述符号表的基础上先生成静态单赋值形式的中间代码，再对所述中间代码执行控制流分析构造出控制流图；所述调度器用于负责整个分析检测过程中的功能调度及规则引擎的执行调度。

在一些实施例中，所述支撑层包括：存储静态分析参数的分析配置文件、存储分析检测规则数据的规则库及一系列执行实际分析检测的规则执行引擎。

图11是根据一示例性实施例示出的一种代码静态检测工具的数据流图，如图11所示，左侧框图是设置分析参数数据流图，分析参数通过分析配置文件或API参数传递后分别由文件交互适配器、API交互适配器进行解析，之后由交互处理器将分析配置参数更新到分析配置文件。

中间框图是执行分析时输入数据流图。待分析的程序通过TC6格式文件或API参数传递后分别由文件交互适配器、API交互适配器解析出待分析的代码；交互处理器将待分析的代码通过功能调用的方式传递至解析器；解析器对输入代码进行解析验证后输出解析后的代码；转换器将输入程序统一转换为ST语言代码；词法分析器对转换后代码执行分析后输出词法序列并填充符号表中词法信息；语法分析器基于词法序列和语法规则执行语法分析构造出抽象语法树并填充符号表中语法信息；构造器基于抽象语法树和符号表结合规则分析需求扩充抽象语法树语义信息并构造IR及CFG；调度器读取分析配置文件中的配置参数，结合规则库计算出本次分析所使用的分析规则，遍历执行分析规则时，先由分析规则生成规则引擎，之后执行规则引擎；规则引擎执行时会综合使用抽象语法树、控制流图，执行规则分析检测逻辑并暂存分析结果。

右侧框图是获取分析结果的输出数据流图。用户获取分析结果时由交互处理器获取分析结果数据并输出格式化的分析结果，之后再由文件交互适配器、API交互适配器根据用户调用方式将分析结果写入文件或通过API返回值返回至调用方。

图12是根据一示例性实施例示出的一种代码静态检测装置1200的框图。如图9所示，本公开实施例提供一种代码静态检测装置，应用于可编程控制器，所述装置可以包括如下几个模块：

设置模块1210，用于设置所述可编程控制器代码的静态分析参数；

分析检测模块1220，用于将所述可编程控制器代码传递到检测工具进行基于所述静态分析参数的分析检测；

输出模块1230，用于依据不同的交互方式输出分析检测结果。

可选地，设置模块1210还用于设置启用的分析检测规则、所述分析检测结果的输出路径以及目标可编程控制器的设备参数。

可选地，分析检测模块1220包括构造模块，用于构造抽象语法树；

分析检测模块1220还包括构建模块，用于基于所述抽象语法树构建控制流图；

分析检测模块1220还包括遍历模块，用于根据所述抽象语法树和所述控制流图遍历执行所述分析检测规则，并保存分析检测结果。

可选地，构造模块还包括第一转换模块，用于将所述可编程控制器代码统一转换为结构化文本语言程序；

构造模块还包括构造子模块，用于基于所述结构化文本语言程序构造抽象语法树。

可选地，构建模块还包括第二转换模块，用于将所述抽象语法树转换为静态单赋值形式的中间代码；

构建模块还包括构建子模块，用于基于所述中间代码构建控制流图。

可选地，分析检测模块1220还包括解析模块，用于根据不同的交互方式将所述可编程控制器代码传递到所述检测工具，并对所述可编程控制器代码进行代码解析。

可选地，遍历模块还包括调度模块，用于按照所述静态分析参数依次调度各分析检测规则对应的规则执行引擎进行分析检测；

遍历模块还包括分析检测子模块，用于所述规则执行引擎根据检测目标选择不同的检测算法进行分析检测，并保存分析检测结果。

可选地，所述分析检测规则包括：

通用缺陷检测规则和特定行业缺陷检测规则。

可选地，输出模块1230还包括API交互模块，用于通过API交互时输出分析检测进度及所述分析检测结果；

输出模块1230还包括文件交互模块，用于通过文件交互时，将所述分析检测进度及所述分析检测结果写入输出文件中。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

本公开还提供一种计算机可读存储介质，其上存储有计算机程序指令，该程序指令被处理器执行时实现本公开提供的代码静态检测方法的步骤。

综上所述，本公开实施例提供一种代码静态检测装置，应用于可编程控制器，所述控制装置包括：设置模块，用于设置所述可编程控制器代码的静态分析参数；分析检测模块，用于将所述可编程控制器代码传递到检测工具进行基于所述静态分析参数的分析检测；输出模块，用于依据不同的交互方式输出分析检测结果。本公开实施例能够对工控行业代码进行静态检测，相比于动态检测技术具有执行速度快、效率高、代价小的优势，此外还能处理特定行业应用程序代码的非逻辑性缺陷。

图13是根据一示例性实施例示出的一种电子设备1300的框图。例如，电子设备1300可以被提供为一服务器。参照图13，电子设备1300包括处理组件1322，其进一步包括一个或多个处理器，以及由存储器1332所代表的存储器资源，用于存储可由处理组件1322的执行的指令，例如应用程序。存储器1332中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件1322被配置为执行指令，以执行上述代码静态检测方法。

电子设备1300还可以包括一个电源组件1326被配置为执行电子设备1300的电源管理，一个有线或无线网络接口1350被配置为将电子设备1300连接到网络，和一个输入/输出接口1358。电子设备1300可以操作基于存储在存储器1332的操作系统。

在另一示例性实施例中，还提供一种计算机程序产品，该计算机程序产品包含能够由可编程的电子设备执行的计算机程序，该计算机程序具有当由该可编程的电子设备执行时用于执行上述的代码静态检测方法的检测代码部分。

以上所述实施例仅表达了本公开的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本公开公开范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本公开构思的前提下，还可以做出若干变形和改进，这些都属于本公开的保护范围。因此，本公开公开的保护范围应以所附权利要求为准。