**对比文件名称**：JP2010250435A_Description_20260105_2300
**目标专利名称**：管理机器人交通工具的有限安全模式操作
**本次调用的模型名称**：DeepSeek最新版本模型
**特征比对表格**
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：一种用于当来自主控制器的控制信号丢失时维持对机器人交通工具的控制的方法<br>**判断结果**：未公开 | 对比文件涉及的是“プラント監視制御システム”（工厂监控控制系统），其技术领域是发电厂、水处理厂、工业工厂等固定设施的监控，而非机器人交通工具（如无人机、自动驾驶车辆）的控制。 | 技术特征A限定的是一种用于“机器人交通工具”的特定方法，其核心应用场景是移动的、自主或半自主的交通工具（如无人机），旨在解决主控制器（如飞行控制器）故障或重启时维持控制的问题。对比文件（JP2010250435A）公开的是一种工厂监控系统，其“コントローラ”（控制器）用于控制工厂内的固定设备（如阀门、锅炉），其解决的问题是控制器故障时控制任务的转移和系统冗余，其应用领域、控制对象（固定设备 vs. 移动机器人）和技术问题（工业过程连续控制 vs. 交通工具动态姿态/轨迹维持）均与目标专利截然不同。因此，对比文件既未直接也未隐含公开技术特征A。 |
| **技术特征B**：通过检测器电路来监视从所述机器人交通工具的主控制器到电子速度控制器(ESC)的控制信号，以检测去往所述ESC的有效控制信号的丢失<br>**判断结果**：未公开 | 对比文件描述了多个控制器（PLC1-PLC4）之间通过“ライブチェック”（实时检查）来相互监视状态。例如，段落[0061]描述了“コントローラ２２の送受信器は、自コントローラ以外のすべてのコントローラに対して、順にライブチェックを行う”（控制器22的收发器，依次对自身控制器以外的所有控制器进行实时检查）。段落[0066]提到“ライブチェック応答のタイムアウト監視を行い、規定時間内に応答がなければ、コントローラ２１は動作停止中と判断し”（进行实时检查响应的超时监视，若在规定时间内无响应，则判断控制器21已停止运行）。 | 技术特征B的核心在于，通过专门的“检测器电路”监视从“主控制器”到“电子速度控制器(ESC)”的“控制信号”，以检测“有效控制信号的丢失”。其应用场景是机器人交通工具的动力系统（电机控制回路）。对比文件公开的是在工厂控制网络中，多个“可编程控制器”之间通过通信网络（控制网络4）互相发送“ライブチェック要求”（实时检查请求）和“応答”（响应）来检测彼此是否“動作停止”（运行停止）。这是一种基于网络通信和心跳机制的控制器状态监测，监测对象是控制器本身的运行状态（在线/离线），而非从一个特定主控制器到一个特定执行器（ESC）的“有效控制信号流”。两者监测的对象、信号类型、目的和技术手段均不相同。因此，对比文件未公开技术特征B。 |
| **技术特征C**：以及响应于检测到去往所述ESC的有效控制信号的丢失，使辅助控制器开始向所述ESC发出用于控制一个或多个电动机的电动机控制信号，以维持对所述机器人交通工具的控制<br>**判断结果**：未公开 | 对比文件在段落[0062]和[0066]描述了当检测到某个控制器（如PLC1）故障时，由另一个控制器（如PLC2）接管其控制任务：“コントローラ２１で実行していたプログラムであるＰＬＣ１用実行モジュールを、次の周期からコントローラ２２で実行するように処理を変更する”（将原本在控制器21上执行的程序，即PLC1用执行模块，从下一个周期起更改为在控制器22上执行）。 | 技术特征C的核心在于，响应于“主控制器到ESC的有效控制信号丢失”，由“辅助控制器”接管并向“ESC”发出“电动机控制信号”，目的是“维持对机器人交通工具的控制”。对比文件公开的是在工厂控制系统中，当检测到一个“可编程控制器”故障时，由另一个同级的“可编程控制器”接管并执行故障控制器的“执行模块”（程序）。这里的“接管”是软件任务/程序执行的接管，发生在控制器层面，且接管的控制器（如PLC2）本身就是系统内另一个功能完整的主控制器。而目标专利的“辅助控制器”是一个功能有限、专门用于在主控制器故障时短暂接管ESC的特定控制器，其控制目标是具体的电机驱动器以实现“安全操作模式”。两者在响应的触发条件（控制信号丢失 vs. 控制器离线）、执行接管的实体（专用辅助控制器 vs. 同级主控制器）、以及控制的目标和目的（直接控制电机以维持交通工具稳定 vs. 执行原控制程序以维持工业过程）上存在本质区别。因此，对比文件未公开技术特征C。 |
| **技术特征D**：执行电动机控制指令集以向所述ESC发出用于控制一个或多个电动机的电动机控制信号，以使所述机器人交通工具执行操纵<br>**判断结果**：未公开 | 对比文件中的控制器（如PLC1， PLC2）执行由“プログラムエディタ”（程序编辑器）创建并编译的“実行モジュール”（执行模块）来控制工厂设备。例如，段落[0021]提到“コントローラ２１、２２、２３、２４にダウンロードされた実行モジュール１０５、１０６、１０７、１０８は、コントローラ２１、２２、２３、２４で実行され...タンク１１の液位を一定に保つ制御...が実行される”（下载到控制器21，22，23，24的执行模块105，106，107，108在控制器21，22，23，24上执行...执行保持水箱11液位恒定的控制...）。 | 技术特征D描述的是“辅助控制器”执行“电动机控制指令集”以控制“ESC”和“电动机”，从而使“机器人交通工具执行操纵”。这特指在机器人交通工具（如无人机）的移动控制场景下，对推进/转向电机的控制。对比文件公开的是工厂控制器执行通用的控制程序（执行模块）来控制工业设备（如阀门、泵），以实现过程控制（如液位控制）。两者虽然都涉及“执行指令/程序以进行控制”，但应用领域（移动机器人 vs. 固定工业设备）、控制对象（电动机/ESC vs. 工业执行器）以及所要实现的“操纵”的具体内涵（飞行、行驶等动态动作 vs. 过程参数调节）完全不同。因此，对比文件未公开技术特征D。 |
| **技术特征E**：确定所述电动机控制指令集是否已完成<br>**判断结果**：未公开 | 对比文件未提及任何与“电动机控制指令集”是否完成相关的判断或机制。 | 技术特征E是目标专利方法中一个具体的判断步骤，与执行特定的“电动机控制指令集”紧密相关。由于对比文件根本未公开适用于机器人交通工具的“电动机控制指令集”及其执行过程（技术特征D未公开），因此也就不可能存在对该指令集是否完成的判断。该特征在对比文件中既无文字记载，也无法从已公开内容中合理推断得出。 |
| **技术特征F**：以及响应于确定所述电动机控制指令集已完成，向所述ESC发出用于控制一个或多个电动机的电动机控制信号，以使所述机器人交通工具取得安全操作模式。<br>**判断结果**：未公开 | 对比文件未提及任何与“安全操作模式”相关的概念，也未描述在完成某个指令集后切换到一种旨在保护设备或系统的特定安全状态。 | 技术特征F是目标专利特有的安全逻辑：在完成预定操纵指令集后，主动控制机器人交通工具进入“安全操作模式”（如悬停、缓慢上升）。这是一个为解决主控制器故障期间安全问题而设计的特定步骤。对比文件关注的是控制任务的冗余和连续性，其“接管”后是继续执行原控制逻辑，并未公开任何类似的、旨在使被控系统进入一种保护性稳定状态的“安全操作模式”概念或切换机制。 |
| **技术特征G**：如权利要求1所述的方法，其特征在于，响应于检测到从所述主控制器到所述ESC的有效控制信号的丢失，使辅助控制器开始向所述ESC发出电动机控制信号包括：断开将所述主控制器耦合至所述ESC的第一信号路径以及连接将所述辅助控制器耦合至所述ESC的第二信号路径。<br>**判断结果**：未公开 | 对比文件未描述任何通过物理或逻辑开关来切换“主控制器”到“ESC”或类似执行器之间信号路径的机制。控制器的切换是通过软件层面改变“実行モジュール”（执行模块）的执行主体来实现的（见段落[0062]）。 | 技术特征G涉及具体的硬件或信号路径切换机制，用于实现控制权从主控制器到辅助控制器的转移。这是一种具体的电路或接口设计。对比文件中控制器任务的接管是通过网络通信和程序执行调度实现的，发生在更高的系统架构层面，并未提及任何底层信号路径（如PWM信号线）的物理或逻辑切换。两者实现控制权转移的技术手段完全不同。 |
| **技术特征H**：如权利要求1所述的方法，其特征在于，进一步包括：确定所述主控制器是否能够恢复向所述ESC发送有效控制信号；以及响应于确定所述主控制器能够恢复向所述ESC发送有效控制信号，使所述辅助控制器停止向所述ESC发送电动机控制信号。<br>**判断结果**：未公开 | 对比文件在段落[0061]和[0066]描述了通过“ライブチェック”（实时检查）来检测控制器是否从故障中恢复（即重新在线并响应）。然而，在其实施例中，一旦一个控制器接管了故障控制器的任务，并未描述在故障控制器恢复后，会将任务交还给它。其系统设计更侧重于故障期间的持续运行，而非主/备控制器之间的动态控制权交还。 | 技术特征H描述了主控制器恢复后，辅助控制器停止控制并将控制权交还给主控制器的过程。这是一个完整的故障恢复闭环。对比文件虽然公开了检测控制器状态（包括可能恢复），但其公开的实施例中，任务接管后是持续由新控制器执行，并未提及或隐含在故障控制器恢复后，任务控制权会“交还”这一步骤。两者的系统恢复逻辑不同：目标专利强调临时接管和交还；对比文件实施例（至少明确描述的部分）侧重于永久性接管以保证连续运行。因此，对比文件未公开“使辅助控制器停止...控制信号”这一交还控制权的步骤。 |
| **技术特征I**：如权利要求3所述的方法，其特征在于，确定所述主控制器是否能够恢复向所述ESC发送有效控制信号包括：检测所述主控制器已完成重引导过程。<br>**判断结果**：未公开 | 对比文件未提及任何控制器的“重引导过程”（reboot process）。其检测控制器恢复是基于网络通信的“ライブチェック応答”（实时检查响应），这只能表明控制器已重新在线并运行，但无法区分是完成了重引导还是其他恢复方式。 | 技术特征I将“主控制器能够恢复”具体化为“检测主控制器已完成重引导过程”。这是一个非常具体的技术实现细节。对比文件完全没有提及“重引导”这一概念，更未将其作为判断控制器恢复的依据。因此，该特征未被公开。 |
| **技术特征J**：如权利要求1所述的方法，其特征在于，所述辅助控制器由存储在存储器中的电动机控制指令配置成向所述ESC发出用于控制一个或多个电动机的电动机控制信号，以维持对所述机器人交通工具的控制。<br>**判断结果**：未公开 | 对比文件中的控制器（如PLC2）确实由存储在“プログラムメモリ”（程序存储器，52）中的“実行モジュール”（执行模块）配置以执行控制功能（见段落[0022]，图5）。 | 技术特征J描述的是“辅助控制器”的配置方式，核心在于其存储的指令是用于向“ESC”发出“电动机控制信号”以“维持对机器人交通工具的控制”。虽然对比文件公开了控制器由存储器中的执行模块配置这一通用概念，但“辅助控制器”这一特定实体及其存储的特定用于控制机器人交通工具ESC的“电动机控制指令”并未被公开（参见技术特征A， C的论述）。因此，该特征的整体技术内容未被公开。 |
| **技术特征K**：如权利要求5所述的方法，其特征在于，存储在所述存储器中的所述电动机控制指令将所述辅助控制器配置成向所述ESC发出用于控制一个或多个电动机的电动机控制信号，以使所述机器人交通工具取得安全操作模式。<br>**判断结果**：未公开 | 对比文件未提及“安全操作模式”这一概念（参见技术特征F的论述）。其控制程序（执行模块）的目标是实现正常的工业过程控制（如液位恒定），而非使系统进入一种保护性的安全状态。 | 技术特征K是技术特征J的进一步限定，强调所存储的指令是用于使机器人交通工具取得“安全操作模式”。由于“安全操作模式”这一概念在对比文件中未被公开，因此该限定特征自然也未被公开。 |
| **技术特征L**：如权利要求5所述的方法，其特征在于，进一步包括：在有效控制信号的所述丢失之前，由所述辅助控制器从所述主控制器接收电动机控制指令；以及由所述辅助控制器将所接收到的电动机控制指令存储在所述存储器中。<br>**判断结果**：未公开 | 对比文件未描述任何控制器在故障发生前从另一个控制器接收并存储其特定控制指令的机制。虽然所有控制器都从工程工具下载程序，但这不是在运行期间从一个主控制器动态接收指令。 | 技术特征L描述了一种动态更新机制：辅助控制器在主控制器正常运行时，周期性地从主控制器接收并存储最新的“电动机控制指令”。这是一种为提高接管后控制连续性而设计的特定交互。对比文件没有公开任何类似的、在运行期间于主备控制器之间动态传递和存储控制指令的过程。 |
| **技术特征M**：如权利要求7所述的方法，其特征在于，从所述主控制器接收到的所述电动机控制指令将所述辅助控制器配置成向所述ESC发出用于控制一个或多个电动机的电动机控制信号，以使所述机器人交通工具维持所述机器人交通工具在有效控制信号的所述丢失之前的姿态、方向或速度。<br>**判断结果**：未公开 | 对比文件未提及任何关于维持设备“姿态、方向或速度”的控制目标。其控制目标是过程变量（如液位、温度）的稳定。 | 技术特征M限定了所接收指令的具体控制目标：维持机器人交通工具在信号丢失前的“姿态、方向或速度”。这完全是针对移动机器人动态状态维持的特有技术问题。对比文件涉及的工业过程控制完全不涉及此类目标。因此，该特征未被公开。 |
| **技术特征N**：如权利要求1所述的方法，其特征在于，进一步包括：在检测到去往所述ESC的有效控制信号的丢失之际初始化定时器；响应于确定所述电动机控制指令集尚未完成，确定所述定时器是否已流逝；以及响应于确定所述定时器已流逝，向所述ESC发出用于控制一个或多个电动机的电动机控制信号，以使所述机器人交通工具取得安全操作模式。<br>**判断结果**：未公开 | 对比文件未提及在任何故障处理场景中使用“定时器”来限制特定指令集的执行时间，并在超时后触发切换到安全模式。 | 技术特征N描述了一个结合定时器和指令集完成状态判断的复杂安全逻辑，用于确保即使在预定的指令集未完成时，也能在超时后强制进入安全模式。这是一个精细的安全保障机制。对比文件完全没有涉及此类机制。 |
| **技术特征O**：如权利要求1所述的方法，其特征在于，进一步包括：执行对所述辅助控制器的测试；确定是否检测到所述辅助控制器中的故障；以及响应于检测到所述辅助控制器中的故障而采取保护所述机器人交通工具的动作。<br>**判断结果**：未公开 | 对比文件描述了控制器之间通过“ライブチェック”相互测试（见段落[0056]-[0061]）。如果检测到故障，系统会让其他控制器接管任务（见段落[0062]），这可以视为一种“采取保护...动作”。 | **隐含公开**。虽然应用领域和具体对象不同，但对比文件公开了“执行对控制器的测试”（ライブチェック）、“确定是否检测到故障”（判断応答超时）以及“响应于检测到故障而采取保护系统的动作”（由其他控制器接管任务以维持系统运行）这一完整逻辑链。本领域技术人员可以从中合理推断出，在包括备用控制器（辅助控制器）的系统中，为了确保备用控制器本身可靠，也需要对其进行测试，并在其故障时采取保护措施（如禁止起飞、紧急着陆等）。尽管目标专利中的“保护动作”是针对机器人交通工具的具体措施，而对比文件是针对工厂系统的任务重新分配，但“测试备用单元并在其故障时触发保护性动作”这一抽象的技术思想是相通的。因此，技术特征O被对比文件隐含公开。 |
根据上述比对，仅技术特征O被对比文件隐含公开。
<<<o>>>