RAMI 4.0架构：基于人工智能与集成安全技术的工业可追溯性解决方案 作者：Carlos Villafuerte、Melissa Moncayo、William O?ate

《Automation》：RAMI 4.0 Architecture for Industrial Traceability with Artificial Intelligence and Integrated Security Carlos Villafuerte, Melissa Moncayo and William O?ate

　　摘要 全球市场竞争的需求要求所有制造公司，无论规模大小，都必须整合工业4.0 (I4.0) 数字技术。工业运营需要完整的供应链透明度，以确保整个过程中的数据保护和真实性。本文档提出了一种基于RAMI 4.0的分布式架构，专为工业环境中的产品追溯而设计。该架构集成了自动化工具、IIoT通信、云存储、人工智能以及使用加密通信协议的安全数据传输。该系统采用混合架构；只有最底层对应于一个具有确定性和随机性动态的模拟制造工厂。在第二部分中，实现了中间层和上层，工厂数据被传输到云实例中，存储在PostgreSQL数据库中，并随后使用自动化脚本进行分析。报告功能通过与ChatGPT-3.5 Turbo结合实现，可视化功能通过Odoo提供。实验测试显示，使用这种认知计算服务时，端到端通信延迟平均不到200毫秒，数据包丢失率为2.67%，报告验证的可靠性为100%。此外，对架构进行系统化漏洞识别过程的结果表明，大多数资产的风险显著降低，风险状态从高或中等变为低或中等。所提出的架构在受控条件下在模拟工业环境中得到了验证，证明了其作为原型的可行性，而不仅仅是一个完全实现的工业解决方案。 1. 引言 当代制造业，特别是中小企业 (SMEs)，面临着与定制产品需求增长、工业过程管理复杂性增加以及需要在高度动态的全球市场中优化有限资源以保持竞争力相关的重大挑战 [1]。为了应对这一形势，采用先进技术对于提高运营效率、降低成本、改善过程质量以及快速适应市场变化至关重要 [2]。在此背景下，已经提出了几种架构框架来支持工业环境中的数字化转型。诸如ISA-95、CIM和RAMI 4.0等模型提供了生产系统内部功能和信息层的分层表示 [3]。其中，RAMI 4.0因其三维方法而脱颖而出，该方法整合了自动化层次结构、产品生命周期阶段和功能层 [4]。这种架构促进了互操作性，并能够逐步将技术集成到现有工业环境中，从而实现模块化和灵活的实施方案 [5]。在这种背景下，工业4.0作为一种成熟的技术范式应运而生，它整合了物联网 (IoT)、云计算、人工智能 (AI) 和信息物理系统 (CPS) 等先进和新兴技术 [5,6]。这些技术共同实现了对工业资产和过程的实时监控和控制 [5,6]。它们的采用支持有效和透明的产品和过程追溯 [7]，对于寻求成本效益高且实用解决方案的中小企业来说尤其具有价值 [8]。智能制造中最关键的挑战之一是实现有效的实时追溯，以便基于生产系统生成的数据进行分析并支持及时决策 [9]。已经提出了整合RFID、IoT、区块链、AI和云计算等技术作为解决这些挑战的潜在方案 [10]。此外，信息物理数字化方法证明了开发用于试点生产线的预测模型的能力，从而提高了过程理解和优化 [11]。尽管取得了这些进展，现有的提案在可扩展性和适应性方面仍存在显著限制。异构系统之间的互操作性和实施的实际复杂性仍然是主要障碍，特别是对于中小企业 [12]。许多解决方案需要强大的基础设施，而这在小型或中型工业环境中并不总是可行的。相比之下，其他解决方案则仅关注高级系统组件，而不与执行级系统进行集成 [13]。一些作者提出了部分解决方案来缓解这些挑战。在 [4] 中，提出了一种通过模块化组件现代化现有系统的灵活架构；然而，这种方法依赖于已经建立的基础设施。在 [1] 中，提出了一种基于ERP的改进方法，虽然提高了过程的灵活性，但其与车间设备的集成有限。另一方面，参考文献[14]侧重于动态模拟以优化生产管理并提高内部效率，但没有整合AI或数字追溯等新兴技术。同样，参考文献[2]探讨了开源ERP系统的使用，显示出经济可行性，但在分析能力和适应工业数据流方面存在局限性。针对制造执行系统 (MES) 的具体提案，如 [15]，承认了它们的协同作用，但没有解决与AI的直接集成问题。在 [16] 中，提出了一个成熟度模型作为诊断工具，但没有明确的技术路线图。与此同时，参考文献 [17] 使用MES和PLC数据进行过程重建以用于模拟目的，尽管它缺乏自动化决策组件。在 [18] 中引入的ERP成熟度模型可以识别实施层级，但没有提供实际的自动化工具。另外，参考文献 [19] 提出了一种用于控制模拟的创造性环境，虽然在测试场景中有效，但在与真实系统的集成方面有限。最后，参考文献 [20] 专注于主要针对工业机器人的开放自动化平台，而不是数据驱动的决策制定。针对这些限制，本研究提出开发一种集成技术模型，将工业模拟与TIA Portal中的工厂I/O和控制编程相结合。控制逻辑通过PLCSim执行，并通过NetToPlcSim单向传输到Node-RED，数据在那里被整合并存储在PostgreSQL数据库中。在此架构的基础上，使用人工智能技术实时分析收集的数据，识别模式并支持决策制定 [21,22]。所提出的解决方案旨在模块化、成本效益高且可扩展，便于其在资源有限的真实工业环境中的适应。值得注意的是，本研究的主要焦点是处理、存储和分析与生产线产品追溯、库存管理、补货和订单准备相关的数据，这些数据在传输到云端后进行处理。这种方法为分布式ERP系统中的战略和运营决策提供了可操作的知识。此外，本研究是在模拟生产环境中进行的，这一选择是由于方法和架构考虑。工业模拟被用作控制的数据生成层，因为这项工作是更广泛的架构的一部分，该架构主要侧重于云端和企业层面的信息处理、分析和利用。因此，本研究强调的不是生产过程本身的物理行为，而是数据的安全获取、传输、存储、智能分析以及在分布式ERP环境中支持决策的数据可视化。 2. 方法论 本研究围绕位于生产现场之上的两个上层功能层构建，符合RAMI 4.0参考模型的标准。中间层作为生产环境和云端之间的桥梁，将数据安全地路由到上层（云端），在那里系统地存储和组织生产过程事件。利用云计算，在Microsoft Azure（美国华盛顿州雷德蒙德市的Microsoft Corporation）平台上实现了一种服务导向的架构，包括用于数据存储的PostgreSQL（PostgreSQL全球开发组，全球社区项目）、用于数据分析的ChatGPT（美国加利福尼亚州旧金山的OpenAI）以及作为企业资源规划 (ERP) 系统的Odoo（比利时布鲁塞尔的Odoo S.A.），主要关注可追溯性和数据可视化。图1提供了所提出架构的概览，突出了实现生产系统从工业3.0范式向工业4.0框架转型的可扩展性的关键工业4.0技术。图1. 基于三层框架的分布式追溯系统总体架构。还应注意的是，只有底层使用了模拟工业生产过程的软件设计，并且故意生成了随机事件，以确保数据遵循概率分布。信息通过NetToPLCSim通信驱动程序传输到中间层，如图2所示。因此，本研究重点关注跟踪供应链中的产品移动（分配、加工、存储和分类），应用AI驱动的数据分析，并分析所提出架构中的安全互操作性。图2. 数据从模拟环境到本地数据管理系统的通信流程。为了更详细地理解上述内容，本节分为五个方法论子部分，详细介绍了云中的安全工业数据通信、数据库中的工业数据管理、使用AI的工业报告自动化、Odoo中的工业数据业务管理（可追溯性和可视化）以及所提出架构中的网络安全风险评估。 2.1. 云中的安全工业数据通信 接下来的方法论步骤是建立一条通信隧道，将本地环境生成的数据传输到远程托管在云端的数据库。在此阶段，从架构的底层到上层实现了一组技术组件：具体来说，集成了灵活的信息流工具Node-RED、基于发布者/订阅者消息传递的MQTT通信协议以及用于消息管理的Mosquitto中间件/代理。首先，通过S7comm协议从中间层获取生产工厂中传感器和执行器的实时数据；然后使用Node-RED和MQTT协议将信息发送到Microsoft Azure Node-RED端点。为了确保端点之间的安全信息交换，为代理和客户端生成了数字证书，并在Mosquitto和Node-RED中配置了通信端口8883；因此，数据传输使用了传输层安全 (TLS) 1.2 协议。一旦建立了中间层和上层之间的安全连接，数据就从本地环境传输到Microsoft Azure中的虚拟机 (VM)。这样，端点节点处理沿生产线捕获的每个事件的发布/订阅和传输（站点之间的部分传输时间和每个站点的处理时间）。选择这种消息解决方案是因为它的轻量级特性、简单性、低带宽消耗以及在资源和设备分布受限的环境中运行的能力。值得注意的是，尽管MQTT不提供原生的语义，但在本案例研究中，Mosquitto成功实时结构化消息并保持了适合所开发的IIoT架构的互操作性。通过这种方式，制造时间数据存储在云端，提供了一个安全可靠的追溯系统。 2.2. 可追溯性记录和数据存储 一旦数据成功传输到云端环境，下一步就是组织信息以便将来可靠高效地检索。由于传输到云端的生产数据来自多个传感器，因此通过其在MQTT主题中的结构进行标识，这使得数据可以有序地发布和订阅。此外，在同一VM中配置了一个PostgreSQL数据库作为存储服务。这种集中式实施策略简化了系统访问、管理和维护，如图3所示。图3. 使用TLS通信和MQTT节点从本地环境到数据库的安全数据流。在PostgreSQL中，可追溯性记录被组织到一个名为“factory_io_event”的表中，该表专门用于捕获零件制造过程中生成的事件。表中的每一行存储并规范化了MQTT结构信息，如传感器ID、生产工厂站点的类型、检测到的零件颜色、检测日期和时间、零件从一个站点传输到另一个站点所需的时间以及零件在每个站点停留的时间。这种信息结构化方法便于提取和查询数据，以便与其他服务（如ChatGPT和Odoo）集成。在这种情况下，使用PostgreSQL图形管理工具pgAdmin4来可视化和验证存储的数据，从而实现生产过程变量的系统监控和检查。这一阶段建立了可追溯性系统的核心，确保所有生产事件都以结构化和可访问的格式持久存储。这种设置使得后续的自动化数据分析和与外部工具（包括用于高级数据处理的AI脚本和决策支持）的无缝集成成为可能。 2.3.**利用人工智能自动生成报告**

一旦数据被存储在云实例中，企业行政部门的首要任务是对作为生产变量记录的历史数据进行关键、全面的分析，这些数据将作为维护、生产和管理流程决策的数据集。为此，设计了一个使用人工智能技术的自动化工作流程来检索特定信息并生成针对每个业务领域的不同类型报告。同时，在公司局域网上的服务器上运行一个Python 3.13.2脚本，作为数据库和AI模型之间的桥梁；也就是说，用户以维护经理、生产经理或CEO的身份登录HTML服务器，依次执行指令以访问PostgreSQL，提取存储在变量中的所有信息，并将其与特定提示一起发送到OpenAI语言模型（如ChatGPT），从而生成.pdf报告；通过ChatGPT API和Python脚本，该报告被发送到接收者角色指定的电子邮件地址。图4展示了集成到Microsoft Azure实例中的两个服务之间的交互流程图，以及维护经理角色的示例提示。

这种基于AI的报表辅助查询方式能够提供更有用、更准确且更符合角色需求的响应，允许根据特定时间范围或预定义的事件数量选择数据。这种方法使主管或管理者能够在不直接访问系统或手动检查数据库的情况下，获得关于生产状态的简洁而详细的概览。此外，还开发了一个轻量级的HTML界面作为控制面板，旨在简化信息共享并促进及时的、数据驱动的决策制定。为了确保流程自动运行，还开发了第三个脚本来顺序协调上述任务。

这种由AI驱动的流程有效地闭合了工业数据收集与可操作洞察生成之间的循环，如图5所示：生产报告中包含执行摘要、加工零件数量、效率分析和建议等细节。通过所提出的自动化工作流程，技术生产数据被转换为全面的、结构化的报告，并直接发送给需要快速、有根据的信息来支持其运营和战略行动的决策者。

**2.4. 使用Odoo与ERP系统的集成**

一旦建立了可追溯系统和自动化报告工作流程，下一步就是将这些信息连接到ERP平台，以集中数据并为业务管理提供更结构化的视图。为此选择了Odoo，因为它具有开源特性、直观的用户界面以及对PostgreSQL的支持。这意味着当新数据被存储时，Odoo会通过拉取连接自动生成对PostgreSQL的查询，并在操作失败时通过回滚来安全地管理这些交易。在这种情况下，本研究提出的架构通过将信息从生产工厂传输到远程实例、存储它，并将其与人工智能和商业智能服务链接起来以进行决策而完成。这些方面无疑为中小企业的数字化转型奠定了基础。ERP模块被配置为显示相关信息，包括库存、产品质量控制和生产情况。在这些模块中，开发了仪表板来显示记录的零件数量、每个生产站点的运营状态以及存储库存与生产需求之间的比较分析。为了改进用户体验，实现了自定义的HTML界面来显示从ERP数据生成的可视化内容。这些可视化元素直接集成到Odoo仪表板中，为没有高级数据库管理技术知识的用户提供了更易于访问的展示层。

图6展示了这种集成的一个示例以及可追溯性指标的可视化，展示了为系统监控和分析开发的仪表板。这种方法允许高层用户直接访问关键绩效指标，从而促进敏捷的数据驱动决策。

**2.5. 系统安全性评估**

鉴于所提出的架构集成了多个工业和信息技术组件，包括过程模拟、工业通信、云服务、数据库、ERP系统以及使用人工智能的自动生成报告，因此对与所开发系统相关的网络安全风险进行了系统评估。该评估采用基于矩阵模型的定性-定量风险分析方法，考虑了适用于分布式工业环境的核心信息安全原则，即保密性（Confidentiality）、完整性（Integrity）和可用性（Availability，简称CIA）。选择这种方法是因为需要一个结构化且可扩展的评估框架，该框架能够整合可测量因素（如可能性和影响）与资产的关键性，从而在复杂的分布式系统中有效优先排序风险。与完全定量的概率模型或正式的渗透测试方法相比，采用的方法在受控实验条件下提供了更实用和可复制的评估策略，无需完全部署的物理基础设施或大量的测试资源。评估涵盖了技术和操作威胁，包括配置错误、服务暴露、工业通信协议中的漏洞以及使用外部服务所带来的风险。尽管进行了受控测试场景来模拟代表性的威胁条件，但必须认识到网络安全评估在很大程度上基于理论风险建模框架，而不是详尽的渗透测试。因此，结果应被视为在定义的实验范围内对系统暴露和缓解效果的结构化评估。

对于每个关键系统资产（如NetToPLCSim通信桥、Node-RED环境、MQTT代理、Azure云基础设施、PostgreSQL数据库、Odoo ERP系统以及人工智能模块），系统地识别并评估了主要威胁、相关漏洞及其对系统操作的潜在影响。风险水平是根据三个因素的加权评估计算的：资产的关键性、发生的可能性和影响的严重性。这一过程得出了一个固有的风险值，从而将其分类为低风险、中等风险或高风险类别。随后，定义并实施了适当的技术和组织安全控制措施，以估计在缓解识别出的漏洞后的剩余风险。这一评估不仅有助于识别系统内的关键安全点，还验证了所提出架构在现实攻击场景下的鲁棒性，确保符合工业4.0环境中的网络安全最佳实践。

**3. 结果**

本节的结果集中在所开发的架构上，该架构涵盖了底层、中间层和顶层之间的通信。因此，所呈现的指标应被视为所提出解决方案在定义的实验框架内的可行性和操作一致性的指示。需要注意的是，只有底层（对应于生产工厂）被模拟；然而，故意修改了生产线参数，包括降低和增加传送带速度、强制激活传感器和执行器以及随机化生产零件（良品和缺陷品）。这保留了关于非理想生产过程的信息。为了满足上述参数，使用了配备第13代Intel Core i7-13652HX处理器、16 GB RAM和NVIDIA GeForce RTX 4060显卡的Dell G15 5530笔记本电脑作为本地工作站。

为了评估所实施的可追溯系统的性能，设计了一系列实验测试来量化从模拟生产过程中每个站点到托管在虚拟机上的远程数据库的数据传输时间。这些测量是在每个站点连续进行70次运行时完成的，考虑了虚拟传感器生成的输入和输出事件。所有实验都在5 GHz Wi-Fi网络上进行，下载速度为198.67 Mbps，上传速度为187.13 Mbps，空闲ping时间为15 ms，下载ping时间为58 ms，上传ping时间为60 ms。这些连接条件用于记录不同层次架构中实验延迟测试的结果。

由于底层和中间层位于同一台本地服务器上，因此观察到快速的非循环通信。同时，通过记录通信过程中的两个时间戳来记录中间层和顶层之间的传输延迟。第一个时间戳是在本地Node-RED实例捕获生产设施生成的事件时记录的，第二个时间戳是在事件成功存储在云端PostgreSQL数据库时记录的。生产设施与云端之间的传输延迟计算为这两个时间戳之间的差异。获得的结果表明，信息传输的平均延迟大约保持在200 ms以下，这在用于非确定性监控时间的IEC61784工业通信协议定义的可接受范围内。

图7展示了从生产线工作站到云实例的数据传输平均延迟结果，这是基于150次测试迭代计算得出的。此外，还展示了传输过程中丢失的数据包情况，从而评估了系统的效率和可靠性。

**结论**

结果表明，所提出的解决方案在定义的实验框架内是可行且操作上是一致的。需要注意的是，只有底层（对应于生产工厂）被模拟；然而，生产线参数被有意修改，包括降低和增加传送带速度、强制激活传感器和执行器以及随机化生产零件（良品和缺陷品）。这保留了有关非理想生产过程的信息。为了满足上述参数，使用了配备第13代Intel Core i7-13652HX处理器、16 GB RAM和NVIDIA GeForce RTX 4060显卡的Dell G15 5530笔记本电脑作为本地工作站。

在评估实施的可追溯系统性能时，设计了一系列实验测试来量化从模拟生产过程中每个站点到虚拟机上托管的远程数据库的数据传输时间。这些测量是在每个站点连续进行70次运行时完成的，考虑了虚拟传感器生成的输入和输出事件。所有实验都在5 GHz Wi-Fi网络上进行，下载速度为198.67 Mbps，上传速度为187.13 Mbps，空闲ping时间为15 ms，下载ping时间为58 ms，上传ping时间为60 ms。这些连接条件用于记录不同层次架构中实验延迟测试的结果。

由于底层和中间层位于同一台本地服务器上，因此观察到快速的非循环通信。同时，通过记录通信过程中的两个时间戳来记录中间层和顶层之间的传输延迟。第一个时间戳是在本地Node-RED实例捕获生产设施生成的事件时记录的，第二个时间戳是在事件成功存储在云端PostgreSQL数据库时记录的。生产设施与云端之间的传输延迟计算为这两个时间戳之间的差异。获得的结果表明，信息传输的平均延迟大约保持在200 ms以下，这在IEC61784工业通信协议定义的可接受范围内。

图7展示了从生产线工作站到云实例的数据传输平均延迟结果，这是基于150次测试迭代计算得出的。此外，还通过展示传输过程中的数据包丢失情况来显示网络行为，从而评估了系统的效率和可靠性。

结果表明，平均来说，分配站的数据传输时间为194.59 ms，其次是加工站208.97 ms，分拣站197.6 ms，存储站198 ms。这些值证实了系统能够在非关键工业环境中保持低于200 ms的延迟水平，这一阈值通常被认为是实时监控控制面板的可接受范围。诸如[23]之类的研究支持这一点，这些研究表明基于MQTT和低成本工业设备的IIoT架构可以实现300 ms或更少的往返延迟，标准差约为20 ms，同时在实际操作条件下保持功能。

根据对构成架构的不同层之间的互连的分析，在实验测试过程中观察到数据传输损失，存储站的总传输中有1.3%，分配站和加工站各有0.66%。虽然这个百分比不会影响系统的整体运行，但它揭示了改进中间层和顶层之间通信链接可靠性的机会。然而，没有记录到底层和中间层之间的数据丢失。

如前文所述，为了开发实验测试，使用Python脚本创建了代表不同业务管理领域的三个角色。通过为维护、生产和执行角色生成企业报告，验证了所提出架构的互操作性。对于这次测试，每个角色生成了10次报告请求尝试，并通过电子邮件验证了响应。所进行的测试反映了互联网服务质量（QoS），确认了操作参数（如延迟、抖动、数据包丢失和带宽）在互联网服务提供商提供的正常范围内。表1显示了实验测试期间的平均延迟、每个角色的报告请求次数以及响应的验证情况。

在认知计算应用程序中，以秒为单位的延迟结果是可接受的，因为请求属于监控和分析应用的范畴。由于AI处理，通信架构中考虑了额外的时间，但这不会影响生产线流程。此外，所提出的架构通过发送给所有三个角色的电子邮件中100%可验证的报告证明了其可靠性。

由于本地工作站运行多个并发进程，它能够实现生产过程的实时监控以及通过中间件（Python ? PostgreSQL ? Python ? ChatGPT ? Python ? email）的多层客户端/服务器通信。图8展示了在执行这些过程期间主要本地工作站资源的平均利用率。结果表明，处理器负载平均接近23%，表明控制、通信和建模任务没有耗尽可用的处理能力。

**总结**

所提出的架构涵盖了底层、中间层和顶层之间的通信，因此所呈现的指标应被视为所提出解决方案在定义的实验框架内的可行性和操作一致性的指示。需要注意的是，只有底层（对应于生产工厂）被模拟；然而，生产线参数被有意修改，包括降低和增加传送带速度、强制激活传感器和执行器以及随机化生产零件（良品和缺陷品）。这保留了关于非理想生产过程的信息。为了满足上述参数，使用了配备第13代Intel Core i7-13652HX处理器、16 GB RAM和NVIDIA GeForce RTX 4060显卡的Dell G15 5530笔记本电脑作为本地工作站。

为了评估所实施的可追溯系统的性能，设计了一系列实验测试来量化从模拟生产过程中的每个站点到托管在虚拟机上的远程数据库的数据传输时间。这些测量是在每个站点连续进行70次运行时完成的，考虑了虚拟传感器生成的输入和输出事件。所有实验都在5 GHz Wi-Fi网络上进行，下载速度为198.67 Mbps，上传速度为187.13 Mbps，空闲ping时间为15 ms，下载ping时间为58 ms，上传ping时间为60 ms。这些连接条件用于记录不同层次架构中的实验延迟测试结果。

因为底层和中间层位于同一台本地服务器上，所以观察到快速的非循环通信。同时，通过在通信过程中的两个阶段记录时间戳来记录中间层和顶层之间的传输延迟。第一个时间戳是在本地Node-RED实例捕获生产设施生成的事件时记录的，第二个时间戳是在事件成功存储在云端PostgreSQL数据库时记录的。生产设施与云端之间的传输延迟计算为这两个时间戳之间的差异。获得的结果表明，信息传输的平均延迟大约保持在200 ms以下，这在IEC61784工业通信协议定义的可接受范围内。

图7展示了从生产线工作站到云实例的数据传输平均延迟结果，这是基于150次测试迭代计算得出的。此外，还通过展示了传输过程中的数据包丢失情况，从而评估了系统的效率和可靠性。鉴于底层与PostgreSQL之间的通信延迟小于200毫秒，实验测试也假设Odoo与PostgreSQL之间的通信是确定性的且延迟低。响应时间取决于查询复杂性和数据量。然而，在本案例研究中，延迟通常保持在1到100毫秒之间。除了性能和延迟评估之外，还进行了安全评估，以识别和分析与所提出的分布式架构相关的风险，考虑了工业通信的不同层次、本地处理和解决方案中涉及的云服务。进行了系统的风险和漏洞识别过程，结果总结在表2中。该分析检查了系统的主要组件，包括NetToPLCSim通信桥、Node-RED工作流、MQTT代理、Azure云基础设施、PostgreSQL数据库、Odoo ERP系统以及基于人工智能的自动报告生成模块，识别了潜在威胁，如数据拦截、工业变量操纵、未经授权的访问、配置错误、拒绝服务攻击和凭证泄露。此外，还评估了每种风险对可追溯性完整性、运营连续性和管理决策的潜在影响。表2. 系统风险、漏洞和潜在影响的识别。在识别出系统风险后，通过受控测试程序系统地评估了表2中列出的每个场景，以评估其对所提出架构的完整性、可用性和运营稳定性的影响。这些评估是通过模拟每种已识别风险的典型威胁条件来进行的，从而在系统背景下表征其关键性。随后，在不同的架构层次上实施了一组与识别的漏洞相一致的安全控制措施，包括通信加固、访问控制执行、安全配置实践和凭证管理机制。部署这些控制措施后，在相同条件下重复测试程序，以评估缓解策略的有效性。这一过程的结果体现在从固有风险级别到剩余风险级别的转变中，如表3和表4所示，提供了实施所提出控制措施前后系统安全状态的比较评估。表3. 系统资产的固有风险评估。表4. 实施安全控制措施后的剩余风险评估。基于之前识别的风险，随后对系统的固有风险进行了评估。在此背景下，固有风险定义为在实施任何安全控制措施之前的风险级别，从而建立了准确的评估每个资产在实际架构中关键性的基准。这项评估使用基于三个基本因素的定量风险分析模型进行，这三个因素是：资产关键性、威胁发生的可能性以及潜在影响。这些因素使用预定义的离散尺度进行了加权。资产关键性被分为三个级别。非常重要性的资产被赋予10的值，这些组件的损坏或不可用会直接且严重影响整个系统的运行。5的值代表中等重要性，与影响关键过程但不会导致系统崩溃的资产相关。1的值表示低重要性，与影响有限且易于管理的资产相关。同样，威胁发生的可能性是根据系统的运营环境来估计的。3的值被赋予高度可能的场景，其中威胁频繁发生或已经观察到；2的值被赋予可能的场景，其中发生是可行的；1的值被赋予不太可能的场景，其特点是频率低且情况特殊。此外，影响严重性根据其运营后果进行分类，3的值被赋予能够停止运营或造成重大损失的高影响场景，2的值被赋予降低系统性能的中等影响场景，1的值被赋予与轻微影响相关且容易缓解的低影响场景。固有风险是通过资产关键性、可能性和影响的乘积来计算的，这种方法在风险评估中被广泛采用，因为它能够反映每个评估场景的相对关键性。根据得出的分数，风险被分为三个级别：1到10之间的分数为低风险，11到30之间的分数为中等风险，31到90之间的分数为高风险，从而能够客观地优先考虑最暴露的资产。结果表明，与工业通信和数据交换相关的组件，如NetToPLCSim通信桥、MQTT代理和PostgreSQL数据库的访问，表现出最高的固有风险级别。这种行为主要归因于使用的工业协议缺乏原生加密、关键服务在网络环境中的暴露以及管理的可追溯性数据的敏感性。这些发现证明了在分析的后续阶段对这些元素应用特定的安全控制的必要性。随后，实施了一组技术和组织安全控制措施，旨在系统地缓解在固有风险评估期间识别的风险。这些措施包括采用TLS的传输层加密机制、基于数字证书的强认证方案、逻辑网络 segmentation、基于角色的访问控制（RBAC）政策、暴露组件的服务加固程序、安全的凭证保护和管理机制，以及旨在防止恶意数据操纵的应用级验证。作为应用这些控制的直接结果，进行了后续的系统评估，以确定剩余风险。这一评估的结果显示在表4中，能够定量衡量实施的安全控制措施的有效性，并清楚地展示了系统整体暴露程度的降低。获得的结果表明，大多数分析资产的整体风险水平显著降低，主要从高或中等风险水平转变为低或受控的中等水平。这种降低确认了所实施的安全措施的有效性，并表明即使在集成工业技术、云服务和人工智能模块的分布式环境中，所提出的架构也能表现出稳健的行为。总体而言，安全评估通过提供一个全面的视角来补充系统性能结果，该视角不仅考虑了效率和延迟，还考虑了可靠性、弹性和在未来实际工业环境中的可行性，其中网络安全是采用基于工业4.0的解决方案的关键因素。总之，这些结果表明，所提出的架构不仅在功能上和稳定性上表现良好，而且在计算资源消耗方面也很高效。它能够在分布式工作负载下运行，而不会出现处理崩溃或内存和网络饱和的情况，这增强了其在实时可追溯性应用中的可行性。这为后续的扩展和集成到物理生产环境中提供了坚实的保证，在这些环境中，运营连续性至关重要。4. 讨论在引用的文献中，产品可追溯性和数据传输安全被作为相关主题进行讨论，尽管它们通常被视为独立的问题。一些研究专注于整个产品生命周期中的跟踪机制，而其他研究则优先考虑使用加密通信协议进行安全信息传输。相比之下，本工作以统一、实时的方式整合了这两种方法，从生产车间到托管在Microsoft Azure上的云实例，并配备了各种服务，如数据库、ERP和认知计算。这种整合保证了整个可追溯过程的数据保密性和完整性。在系统开发过程中，最显著的挑战之一是在本地环境和云基础设施之间建立安全稳定的通信渠道。虽然MQTT协议在数据传输方面非常高效，但其使用TLS的安全配置引入了严格的认证要求。在这种情况下，使用通用证书被证明是不够的，因为Mosquitto代理需要有效且正确签名的证书。这需要在服务器和客户端两侧生成证书，包括相应的私钥。这些挑战突显了在IIoT系统中考虑网络安全的极端重要性。此外，选择PostgreSQL是因为其健壮性和与所提出架构的兼容性，并且在实验测试中表现出了足够的性能。测量到的数据传输时间保持在IEC61784通信协议规定的监控和分析过程的可接受范围内，延迟低于300毫秒。由集成的人工智能模块生成的电子邮件传递也受到电子邮件服务提供商安全策略的限制，这些策略需要先进的认证机制来防止未经授权的消息传输。该服务实施了两层安全验证过程，需要生成特定于应用程序的密钥来授权自动化系统或第三方系统的访问。此外，还验证了所提出的通信架构（Python ? PostgreSQL ? Python ? ChatGPT ? Python ? 电子邮件）是可靠的，并且在集成认知计算时实现了预期的响应时间。然而，Python脚本的计算性能较低；因此，可以在微处理器上运行轻量级算法，这适合资源有限但寻求数字化转型的公司。关于数据传输安全，来自Microsoft Azure虚拟机配置的额外困难特别是关于入站和出站防火墙规则。这些规则根据源IP地址和目标IP地址来调节网络流量，这可能会使通信配置复杂化。虽然允许来自任何IP地址（0.0.0.0/0）的连接简化了连接性，但这代表了显著的安全漏洞。因此，确保MQTT流量仅通过适当的端口传输而不损害系统完整性至关重要。由于Odoo建立与PostgreSQL数据库的正确连接所需的权限，复杂性增加了，这需要精确定义角色、凭证和数据库级别的访问权限。然而，对于本工作中处理的系统关键性水平，PostgreSQL提供了适合的数据存储和管理解决方案。此外，它还提供了与Odoo的原生通信，促进了高效的查询执行。从持续改进的角度来看，通过先进的监控、检测和响应机制加强网络安全架构是至关重要的。尽管当前的控制在缓解剩余风险方面有效，但集成IDS/IPS系统和日志关联将增强对持久威胁的防护。同样，身份和信任管理必须通过集中服务、自动凭证轮换和严格应用最小权限原则来实现可扩展性。最后，采用零信任模型将通过消除内部网络中的任何隐含信任假设来加强节点之间的安全性。结果验证了跨多个层的互操作性和不同服务的集成，以便将行业从工业3.0数字化改造为工业4.0。然而，中间层和上层之间的通信协议是MQTT通过Mosquitto代理，其中传输数据的结构主要取决于程序员，这效率低下并导致实施延迟。提出的解决方案是使实现的IIoT系统在数据传输方面更加健壮和高效，即通过用一个能够保证传输数据包语义完整性的代理替换Mosquitto代理来使其更符合RAMI参考。5. 结论基于RAMI 4.0框架的三层分布式架构，并结合当前技术工具，被证明是从工业3.0扩展到工业4.0的可行且高效的解决方案，同时还集成了生产线上的产品可追溯性系统。实施的架构在涉及多层通信和云服务（如数据库、Odoo和认知计算）的测试中展示了可靠的互操作性。鉴于信息的机密性质，在中间层和上层之间建立MQTT通信协议是必要的，并且根据框架的IIoT基础设施安全标准，需要在云计算服务中实施数据传输和认证的安全系统。在本案例研究中，系统通过了TLS 1.2标准的认证，并为Odoo和报告请求生成了用户名和密码。实施的架构通过整合数据传输的加密机制、访问控制和云服务的认证来确保数据保护和系统完整性。结果表明，这些控制有效缓解了与服务暴露、层间通信和IIoT环境中数据管理相关的风险。尽管验证是在受控环境中进行的，但提出的解决方案在面对常见威胁场景时表现出稳健的行为，为在实际工业环境中的实施提供了可靠的基础。根据工业通信在监控和分析系统中的国际标准，延迟应小于300毫秒。所开发的架构实现了上下通信层之间平均延迟仅为200毫秒的显著成就。此外，文中强调了使用像PostgreSQL和Odoo这样的原生服务对于实现低延迟通信的重要性。同时，报告请求系统的可靠性也得到了重点强调。该系统采用了Python ? PostgreSQL ? Python ? ChatGPT ? Python ? email的通信架构，能够通过电子邮件实现100%的报告验证。虽然报告处理的延迟在4到6秒之间，但这并非由架构本身导致的，而是由于认知计算服务的特性所致。文中还指出，该过程的计算性能得到了优化，从而使得该系统有可能在配备轻量级算法的微控制器上实现。需要明确的是，只有底层被进行了建模；正如前文所述，中间层和上层已经实现。为了模拟一个具有可变数据的生产流程，输送机中的加速度参数被有意修改，零部件被随机排列，并设置了不同的生产批次特征，以便区分处于良好状态和不良状态的零部件。