新机械法规下,技术文件新增了什么?安全软件源代码、编程逻辑什么时候要准备?

新机械法规下，技术文件新增了什么？安全软件源代码、编程逻辑什么时候要准备？

新机械法规提到“源代码”，是不是以后做CE，都要把设备程序交出去？

安全程序由外部供应商开发，设备商手里只有可运行的程序，够不够？

自主机械的系统资料，是设计时就要准备，还是等主管机关来查时再整理？

这些问题不能只看附件中的几个关键词。需要先分清楚：制造商应当编制保存什么、主管机关可以依法要求提供什么，以及客户应当随设备取得什么。

《机械法规》（EU）2023/1230的主体要求自2027年1月20日起适用。本文依据2026年7月27日英文合并文本，对照《机械指令》2006/42/EC，重点讨论技术文件的变化。以下设备场景均为说明条款的假设示例。

需要先说明一个时间边界：本文讨论的是新机械法规适用后的技术文件要求。2027年1月20日前已经依据2006/42/EC合法投放欧盟市场的机械，还需要结合新法规第52条的过渡规定判断，并不是新法规开始适用以后，所有存量产品都要自动重新按照附件IV编制一套技术文件。

一、技术文件、监管调取和客户交付，是三种不同义务

假设一家设备商交付一台自动装配机，设备里既有普通顺序控制程序，也有安全相关程序。

围绕这台设备，至少需要分清三种文件用途：

说明书属于技术文件的一部分，并不意味着技术文件中的全部内容都属于客户交付文件。

例如，用户需要知道如何安全操作、维护和排除故障，但这并不自动产生取得设备商全部安全软件源代码的权利。

如果采购合同另外约定交付程序、图纸、源代码或者其他设计资料，则还需要结合合同判断。合同义务和机械法规下的法定义务不能混在一起。

另外，采用需要公告机构参与的符合性评定程序时，制造商还须按照相应程序向公告机构提交评审所需资料。这个环节也不能与主管机关进行市场监管时的文件调取混为一谈。

二、安全相关软件源代码：明确进入技术文件范围，但提供有条件

新法规附件IV Part A(m)明确提到：

the source code or programming logic of the safety related software

安全相关软件的源代码或编程逻辑。

这里首先限定了对象。

“安全相关软件”同时限定前面的“源代码”和“编程逻辑”，不能把这一条读成：

安全软件的源代码，或者设备内全部程序的编程逻辑。

也就是说，新法规并没有要求设备商因为做CE，就把设备内部所有PLC程序、HMI程序、MES接口程序、数据采集程序全部纳入这一项。

同一项随后规定：

further to a reasoned request from a competent national authority

根据有权限的国家主管机关提出的有理由的请求。

并进一步附加条件：这些资料必须是主管机关核查附件III基本健康与安全要求符合性所必需的。

第10(3)条也有对应规定。

因此，不能把这一项理解成：

从2027年开始，所有设备商做CE都必须把完整软件源代码提交给客户、认证机构或者任何提出要求的人。

但反过来，也不能理解为：

“既然主管机关提出请求以后才需要提供，那在此之前完全不用准备，供应商以后能不能提供也无所谓。”

第10(2)条要求制造商在机械或相关产品投放市场或投入使用之前编制附件IV Part A规定的技术文件；第10(3)条又专门提到技术文件中所包含的安全相关软件源代码或编程逻辑。

因此，更稳妥的理解是：

制造商应当在符合性评定阶段把适用的安全相关软件证据纳入技术文件的受控范围，并确保在法定条件满足时能够提供。主管机关的请求条件限制的是何时、向谁以及为核查提供什么，并不意味着这些资料可以等收到监管请求以后再从零形成。

至于资料必须由设备商本人保存，还是由软件供应商、受控系统或其他安排保存，新法规在这里并没有规定统一的保管模式。

1. 安全相关与否，不能只看程序装在哪里

一台设备中，用于产量统计和报表导出的程序，不会因为安装在同一台PLC或同一台工业计算机上，就自动成为A(m)所指的安全相关软件。

但是，如果某段程序参与安全限速、防护装置状态处理、安全位置判断，或者直接影响危险运动的安全控制，就不能仅凭：

“这是普通PLC里的程序。”

或者：

“这不是Safety PLC中的程序。”

就把它排除在分析之外。

应当结合程序的实际作用、与安全相关控制系统的关系，以及其失效或修改是否可能影响机械安全来划定范围。

这里也不等于认可普通控制器可以直接承担任何安全功能。控制架构本身是否适合，需要根据相应的安全要求另行评估。

2. “源代码或编程逻辑”，不等于两者必须全部同时提交

法规使用的是：

source code or programming logic

源代码或编程逻辑

因此，没有普遍要求制造商在所有情况下同时准备和提供两者。

但这个“或”也不能进一步理解为：

无论系统多复杂，制造商都可以任意选择信息量最少的一种资料。

法规并没有给“programming logic”规定统一的文件格式，也没有规定只要有一张简单流程图，就必然能够代替源代码。

最终仍然要回到一个问题：

这些资料是否足以支持主管机关完成对附件III相关基本健康与安全要求的符合性核查。

如果某项安全功能的判断条件、状态转换、异常处理、限制条件或者安全输出逻辑无法从现有资料中理解，仅仅因为某份文件名称叫“Programming Logic”，并不能当然证明已经满足要求。

3. 只有可执行程序，够不够？

这对大量采用外包软件开发的设备商非常现实。

例如，一家设备商采购了一套安全相关控制程序。

供应商最终只给设备商一个能够下载到控制器中的编译文件或者可执行文件，设备商无法查看其中的安全逻辑，也没有合同约定供应商以后需要提供相应资料。

这种情况下，不能简单认为：

“程序现在可以正常运行，所以技术文件已经足够。”

新法规第3(35)条对“source code”进行了定义，指向的是产品当前安装软件版本中，以人能够明确理解的编程语言表达的软件内容。

一个单纯的编译文件、二进制文件或其他不可理解的可执行程序，本身通常不能等同于这一意义上的源代码。

如果设备商手中只有无法反映安全相关程序逻辑的可执行文件，同时也没有办法在需要时取得相应的源代码或者足以支持符合性核查的编程逻辑资料，就不能认为仅凭这个可运行程序已经稳妥解决了A(m)的问题。

这并不意味着设备商为了做CE，就必须购买外部供应商全部源代码的所有权。

真正需要解决的是：

制造商能不能履行自己的符合性证明和监管配合责任。

4. 有理由的请求，不等于必须先发生事故

条文没有把“已经发生事故”列为主管机关提出请求的必要前提。

因此，不能想当然的认为：

“只有设备出了事故，监管机关才有权要求软件资料。”

另一方面，主管机关依法取得这些资料，也不等于资料会被向社会公开。

新法规第49条规定了对商业秘密、知识产权等信息的保密要求以及相应例外。

但是，保密要求同样不能反向理解成：

“这是商业机密，所以制造商可以一概拒绝向主管机关提供。”

商业秘密保护和依法履行监管配合义务，是两个需要同时满足的问题。

三、有一类系统资料，不能等主管机关来问以后再准备

紧接着的附件IV Part A(n)，与A(m)的条文结构并不一样。

它针对的是：

接收传感器数据的（sensor-fed）、远程驱动的（remotely-driven）或自主的（autonomous）机械及相关产品，并且其安全相关操作由传感器数据控制。

原文中的一个关键条件是：

if the safety related operations are controlled by sensor data

如果安全相关操作由传感器数据控制。

对于符合这些条件的产品，应在适当情况下纳入有关系统一般特征、能力和限制，以及所使用数据、开发、测试和验证过程的说明。

A(n)本身没有设置“先收到主管机关有理由的请求”这一前提。

因此，它需要结合第10(2)条理解：

对于适用的设备，这类资料应当在机械投放市场或者投入使用之前，作为正常技术文件准备工作的一部分形成。

不能等监管机关来查以后，才第一次回头整理系统能力、数据来源和验证逻辑。

这不只是机器学习设备的问题

假设一台自主搬运设备通过激光扫描器、摄像头或者其他传感器获取周围环境信息，并依据这些信息执行安全相关的减速或者停止。

即使这套系统完全采用固定规则，没有使用机器学习，也不能仅凭：

“我们这个不是AI。”

就直接排除A(n)。

需要解释的问题可能包括：

• 系统在什么使用条件下具备所声明的能力；

• 传感器数据适用于哪些环境和工作范围；

• 系统存在哪些已知限制；

• 系统如何开发；

• 测试和验证覆盖了哪些运行条件；

• 数据异常或者环境变化可能怎样影响安全相关操作。

这些是理解法规要求时可能需要考虑的工程问题，并不是法规规定的一张统一文件目录。

反过来，一台普通设备上安装了摄像头，也不能因为：

“设备有传感器。”

就自动认为必须提交一整套自主系统或者机器学习资料。

仍然需要回到A(n)规定的具体适用条件，看这些传感器数据是否真正控制安全相关操作。

还有一个需要控制的边界：

A(n)要求的是有关系统、数据以及开发、测试、验证过程的说明，不能直接扩大成“所有原始数据、全部训练数据集、全部算法资料都必须无条件纳入技术文件并提交”。

具体证据需要做到多深，仍应结合系统性质以及证明符合性的需要判断。

另外，这里讨论的是机械法规附件IV A(n)本身的技术文件要求，并不代表满足A(n)以后，就已经覆盖了所有可能适用的AI法规义务。

2026年欧盟又进一步调整了AI Act与机械法规之间的衔接机制。对于同时涉及特定高风险AI系统的机械，后续还需要继续关注依据机械法规第8条制定的附件III补充要求，不能把A(n)理解成整个AI合规体系的替代品。

四、自演化系统还要看风险评估和运行证据，不能只增加一份算法说明

“自主运行”和“自演化”不是同一个概念。

一台机械可以按照预先固定的逻辑，自主完成路径规划或者动作控制；

另一台机械的行为或逻辑，则可能在运行过程中发生设计上预期的演化。

两类系统需要准备的技术证据并不完全相同。

对于具有完全或者部分自演化行为或逻辑、并按不同自主程度运行的机械，新法规附件III还有直接影响技术文件准备的要求。

1. 风险评估需要考虑预期演化

附件III通用原则第1项要求，风险评估和风险降低应包括：

在机械投放市场时能够预见的，由其预期自演化行为或者逻辑在生命周期中产生的危险。

例如，一台设备能够根据运行经验调整运动策略。

制造商不能只证明：

“设备出厂时使用的初始轨迹是安全的。”

如果系统设计允许其行为在之后继续发生预期变化，就还需要考虑：

这些变化是否可能产生新的危险，或者改变原有风险水平。

因此，相应的风险评估、设计限制以及验证证据，也不能只记录初始调试完成时的状态。

2. 安全边界需要在设计阶段建立

附件III第1.2.1条要求，在风险评估中确定安全功能的限制，并防止可能导致危险情况的设置或者规则修改，其中包括学习阶段发生的相关修改。

对于该条规定的自演化控制系统，还要求系统不得使机械执行超出已定义任务和运动空间的动作，并应能够随时进行纠正，以维持机械的固有安全性。

这些首先是产品设计要求。

技术文件需要做的是留下与这些设计要求相对应的证据：

• 安全边界如何定义；

• 哪些参数允许改变；

• 哪些规则不能改变；

• 系统如何防止突破安全限制；

• 相应限制怎样经过测试和验证。

因此，增加一份“算法说明书”，并不能自动证明自演化机械满足这些要求。

3. 部分运行记录必须提前具备记录能力

第1.2.1条还规定：

对于该条所述的自演化控制系统，确保安全功能的软件安全系统，包括安全元件，应当能够记录机械投放市场或者投入使用以后，与安全相关决策过程有关的数据。

相关数据在采集以后应保留一年，并专门用于在主管机关有理由提出请求时证明机械符合要求。

这里必须把两个动作分开：

“主管机关提出请求”触发的是资料用于证明符合性，并不意味着设备可以等收到请求以后才开始记录。

如果设备本身没有事先具备相应记录能力，那么主管机关后来要核查某次已经发生的安全相关决策时，过去的数据根本不存在。

因此，这项要求从工程实施上必须在设备设计阶段提前考虑。

4. 一年、五年和十年，是三种不同的时间要求

同一条还涉及另一类追踪日志：

与干预有关的数据，以及上传到机械中的安全软件版本，应具备相应的追踪能力。

法规对这里使用的是：

enabled for five years after such upload

即与相关安全软件上传后的五年期限相联系。

由于该款同时涉及干预相关数据和上传的安全软件版本，不能进一步简单改写成：

“所有干预数据必须统一保存五年。”

更不能把这一规定与下面两个期限混在一起：

• 安全相关决策过程数据：采集后一年；

• 第10(3)条规定的技术文件和EU符合性声明：至少十年。

这三类要求的对象、目的和起算逻辑都不同。

不能把它们合并成：

“新机械法规要求所有AI机械把全部运行日志统一保存十年。”

五、对照旧指令，哪些属于新增，哪些只是细化或者结构调整？

旧机械指令并没有忽略技术文件，更不是“以前做CE只需要一张证书”。

2006/42/EC附件VII已经要求技术文件包括风险评估资料、控制回路图、必要图纸和说明、计算和测试结果、说明书，以及批量制造时采取的内部措施等内容。

因此，新法规的变化需要逐项区分。

此外，附件IV A(i)不只是简单写“说明书副本”，还涉及附件III第1.7.4节规定的信息。

A(k)也明确涉及，在适用情况下，被纳入机械中的机械、相关产品以及受其他欧盟协调立法覆盖产品的符合性声明。

这些变化提示设备商：

不能只是把原来技术文件夹里的“Annex VII”改成“Annex IV”，然后认为工作已经完成。

还需要逐项检查：

新法规要求证明的内容有没有变化。

有些变化并不一定表现为新增一种文件名称。

例如，新法规增加或者细化了：

• 软件和数据防篡改；

• 自演化控制；

• 自主系统的限制；

• 传感器数据驱动的安全操作；

• 安全软件及相关追踪要求。

即使技术文件里仍然叫：

风险评估 

控制系统说明 

验证报告 

测试记录

这些文件里面真正需要证明的事项，也可能已经增加。

六、设备商真正需要提前落实的，是资料范围、对应关系和可取得性

1. 技术文件不能在收到监管请求后才从零编制

第10(2)条明确要求：

在机械或者相关产品投放市场或投入使用之前，制造商应当编制技术文件。

因此，安全要求清单、风险评估、必要图纸、控制系统说明、计算和测试结果，以及适用的A(n)系统说明，都应当进入正常的产品设计和符合性评定过程。

A(m)中的源代码或者编程逻辑带有主管机关请求条件，不能反过来用于推迟整个技术文件的准备。

正确区分应该是：

文件准备义务在前，特定资料的监管提供条件在后。

2. 资料必须能够对应实际设备和实际软件状态

第3(35)条对源代码的定义涉及产品：

currently installed version of the software

当前实际安装的软件版本。

这一点对设备商很重要。

例如：

现场设备已经升级到V2.4版本，但技术文件中保存的程序资料和验证记录仍然对应V1.7；

或者现场安全参数已经发生变化，但保存的测试报告仍然对应最初出厂设置。

这种情况下，即使技术文件数量很多，也未必能够支持对实际机械状态的核查。

工程上应建立：

设备身份—软件版本—安全配置—验证证据

之间的对应关系。

法规没有规定制造商必须使用某一种版本管理软件或者某一种配置管理系统。

但是资料必须能解释：

当前这台设备，为什么仍然满足它所声明的安全要求。

3. 外包开发不能留下无法调取的资料缺口

例如，一家设备商采购外部开发的安全相关软件。

设备交付时，只取得一个能够运行的软件文件。

合同中没有约定：

• 源代码或者编程逻辑由谁保存；

• 软件版本如何管理；

• 以后监管机关提出合法请求时供应商是否需要配合；

• 软件供应商停止合作以后资料怎么办。

这种模式真正的风险并不是：

“客户以后会不会要求拿到我们的源代码。”

而是：

制造商自己还能不能履行机械法规要求的符合性证明和监管配合责任。

因此，设备商应提前落实：

• 哪些资料属于需要受控的安全相关资料；

• 资料由谁保存；

• 怎样与具体软件版本建立对应；

• 在合法请求出现时通过什么机制取得；

• 供应商停止合作以后责任如何继续履行。

具体采用合同条款、受控存储、第三方托管还是其他方式，应根据产品、软件供应链和知识产权安排判断。

机械法规并没有在A(m)中统一规定：

“所有设备商必须购买供应商源代码。”

也没有规定：

“必须采用某一种源代码托管服务。”

真正需要保证的是制造商自己的法定义务不会因为外包而出现空档。

4. 十年保存不是新要求，但起算点不能继续照搬旧指令

旧机械指令附件VII Part A第2点规定：

技术文件应在机械制造之日以后至少十年内可向主管机关提供。

批量制造时，以最后一台机械的制造日期作为相应起点。

新法规第10(3)条则规定：

在机械或者相关产品投放市场或投入使用以后至少十年，制造商应保存技术文件和EU符合性声明，供市场监管机关使用。

所以：

十年保存并不是新机械法规第一次增加的责任。

真正发生变化的是起算规则。

设备商以后不能继续不加区分地把旧指令下“制造日期/最后一台制造日期”的逻辑直接套到新法规。

5. 半成品机械也有对应要求

本文主要围绕附件IV Part A讨论机械和相关产品，但半成品机械并不是没有类似要求。

附件IV Part B(k)、B(l)分别规定了与：

• 安全相关软件源代码或编程逻辑；

• 特定传感器控制系统资料；

相对应的要求。

第11(2)、11(3)、11(10)条则分别规定制造商编制文件、保存文件以及配合主管机关的责任。

不过，半成品机械的技术文件范围，应围绕：

与该半成品机械相关的基本健康与安全要求，以及其预期集成功能

来准备。

不能把整机附件IV Part A的所有内容机械地全部复制过去。

其技术文件和EU装配声明至少十年的保存期，则以半成品机械投放市场作为相应时间节点。

七、技术文件真正要解决的，不是“文件够不够多”

新机械法规出现“源代码”“编程逻辑”“数据”“自主”“自演化”等词以后，很容易形成两个极端理解。

一种是：

“以后做CE是不是连整套PLC程序都要交出去？”

另一种是：

“反正监管机关平时不会来查，等真的有人要求再准备也来得及。”

这两种理解都过于简单。

对设备商真正重要的，是能够回答几个问题：

某项安全功能为什么可靠？

现场实际使用的是哪个软件版本？

这个版本改变以后，原来的风险评估和验证结论是否仍然成立？

自主或者自演化系统的能力边界在哪里？

某次软件修改是否仍然处于已经验证的安全范围内？

如果主管机关依法要求核查，制造商现有资料能不能与实际设备状态对应起来？

如果这些问题无法从现有资料中得到解释，那么即使技术文件文件夹里已经塞了几十份PDF，也未必真正解决了符合性证明的问题。

前文《软件也能成为“安全元件”？新机械法规为什么特别关注软件？》讨论的是软件什么时候可能成为机械法规中的产品和安全元件问题。

本文讨论的则是另一层：

当软件、传感器数据、自主控制和自演化行为真正进入机械安全以后，与它们有关的证据应当怎样进入技术文件体系。

两者需要结合，但不能相互替代。