産業用ロボットおよびコボットはCRAの「重要製品」に該当するか

産業用ロボットまたはコボットの分類ルート

アームハードウェアではなく、販売形態から始めます。システム統合者向けに販売される6軸アームと、小規模工房向けに完成コボットセルとして販売される同じアームは、CRA上は異なる製品です。ルートは、買い手が何の対価を支払っているか、どのコントローラーとペンダントが付属するか、メーカーがフリートクラウド、安全設定、OTAアップデート経路も供給するかどうかによって決まります。

上図はルート選択を示します。下のマトリクスは境界メモを示します。バリアントが定まれば、メーカーがそのバリアントについて埋められるべき証拠行はこれらです。

ルーティング補助は境界メモを書く前に使うものであり、メモの代替ではありません。メモには引き続き、正確なアームモデル、可搬質量およびリーチ、コントローラーキャビネット、ペンダント、プログラミング環境、安全設定の範囲、フリートクラウド、OTAサービス、用途を記載する必要があります。完成コボットセルについては、買い手が依拠する協働運転モード（速度・分離監視、力・速度制限、ハンドガイディング、または安全定格モニタード停止）を明示します。

次に、別のリスト掲載機能が実質を担っていないかを確認します。CRAは、製品の中核機能がリスト掲載カテゴリーに該当する場合に、その製品を重要製品として扱います。コントローラーが組み込まれているという事実のみでロボットが重要カテゴリーに移ることはありません。販売の主体が、ファイアウォールゲートウェイ、VPNアプライアンス、ネットワーク管理システム、SIEMコネクタ、または改ざん耐性チップを中心に構築された堅牢化コントローラーである場合は、まずその中核機能を分類し、アームを周辺機器として扱います。

コンポーネント販売の場合、完成セルカテゴリーに無理に当てはめないでください。システム統合者向けに販売される6軸ロボットアームも、なおデジタル要素を含む製品であり、セキュア・バイ・デザインの証拠、アップデート経路、脆弱性ハンドリングプロセス、サポート期間の表明、統合者向け文書を必要とします。ルートは標準のままで、責任は統合者と分担されます。

分類メモは次の4つの問いに答える必要があります。

1. このリリースはロボットアーム、完成コボットセル、または他の機械に組み込まれたロボットのいずれとして販売されるか。
2. ロボット動作がこの製品の中核機能か、それとも他のリスト掲載機能（ファイアウォール、VPN、ネットワーク管理、セキュリティ関連マイクロコントローラー）が実質を担っているか。
3. 想定機能のために供給されるデジタル要素は何か。アームファームウェア、安全設定、ペンダント、プログラミング環境、OTAサービス、フリートクラウド、脆弱性ハンドリングプロセス。
4. メーカーの提供範囲外となるシステムはどれか。顧客のセルロジック、顧客の安全PLC、工場ネットワーク、サードパーティーの視覚ソフトウェア、顧客のMESまたはSCADA。

ロボット製品境界の範囲

ロボットメーカーにとって、コンプライアンス境界はアーム単体であることはほとんどありません。境界は、上市された製品と、想定される動作および安全機能に必要なデジタル要素に沿って引かれるべきです。

通常、ロボットメーカーの境界に含まれるもの：アームファームウェア、関節コントローラーファームウェア、コントローラーキャビネットのオペレーティング環境、安全コントローラーファームウェア、ペンダント、プログラミング環境、OTAサービス、脆弱性ハンドリングプロセス。

メーカーが提供の一部として販売しない限り、通常、境界外となるもの：顧客のセルロジック、顧客が記述した安全設定、工場ネットワーク、サードパーティーのエンドエフェクター、サードパーティーの視覚ソフトウェア、顧客のMESまたはSCADA、顧客の安全PLC。

適用される適合性評価ルート

ロボットファイルのアーキテクチャチェックポイント

ロボットリリースファイルは、汎用のOTチェックリストではなく、実機に沿って構成すべきです。統合者向けに販売される単体アーム、中小企業向けに販売される力制限コボットセル、包装ラインに組み込まれたロボット、視覚機能を備えたクリーンルームロボットは、クラス論議は共有できても、必要な工学的記録は異なります。

1. 動作権限経路。 動作、パラメーター、または安全設定を変更し得るすべての経路を特定します。ペンダント、エンジニアリングステーション、ベンダークラウド、ベンダーサービストンネル、USB転送、セルコントローラーからのフィールドバス、任意のリモートアシストチャネル。
2. ローカル露出。 試運転後および各アップデート後、コントローラーで到達可能なサービスをスキャンします。リリースファイルには、到達可能なサービス、認証を要するサービス、デフォルトで無効なサービスを示すべきです。
3. 顧客システム。 顧客のセルロジック、顧客の安全PLC、工場ネットワーク、サードパーティーの視覚ソフトウェア、MESまたはSCADAは、メーカーがその層を販売しない限り、ロボットメーカーの製品の範囲外として扱います。
4. アップデート権限。 アップデート権限を双方向のやりとりとして扱います。コントローラーがアップデートメタデータを確認または受信し、アップデートサービスがその正確なコントローラーバリアントおよび安全ファームウェアリビジョン向けの署名済みファームウェアバンドルを返します。署名付きアップデート、ダウングレード拒否、機械への影響、リカバリー、ロールバックの記録をリリースに紐付けて保管します。
5. サプライヤー入力。 サーボMCU、エンコーダー、セーフティMCU、フィールドバススタック、視覚モジュール、RTオペレーティングシステム、プログラミングランタイムのそれぞれに、明示された担当者、バージョン、アドバイザリー監視、リリース判断を付与します。
6. サポートアクセス。 サービストンネル、診断、リモートアシストセッションを第2の動作権限経路にしないようにします。トンネル無効化、レダクション、監査サンプルの記録を保持します。
7. 市販後ループ。 脆弱性報告、重大インシデント、サプライヤーアドバイザリー、フィールド故障は、脅威リスト、残留リスク記録、リリースファイル、次回リリースゲートを更新します。

下のセルダイアグラムは、ワークドエグザンプルよりも意図的に広範に描かれています。ファイルを正確な出荷バリアントに絞り込む前の、製品ファミリー境界チェックとして使用してください。6軸アーム、コボット、クリーンルームバリアント、パレタイジングバリアント、エンドエフェクターと一緒に販売されるロボットは、それぞれ異なる証拠セットを必要とします。

このレイアウトに該当する実在のOEMコントローラーには、ABB OmniCore、KUKA KR C5 (KSS)、iiQKA.OSを実行するKUKAコントローラー、FANUC R-30iB Plus、安川 YRC1000、ユニバーサルロボット PolyScope Xなどがあります。上記のパーティションはこれらすべてに共通します。メーカー製品ファイルがアーム、コントローラー、オンデバイスソフトウェアの境界を保持し、顧客のセルロジック、工場LAN、顧客所有ツールは、メーカーがその層も販売しない限り境界外にとどまります。

ロボットのリスクアセスメント構成

この例は、リリースファイルにそのまま貼り付けるためのテキストではなく、想定される深さを理解するために用います。ロボットメーカーは自社のアーム、関節駆動、コントローラー、安全コントローラー、ペンダント、プログラミングランタイム、フリートクラウド、サプライヤー、販売主張、サポート期間、リリースプロセスに対してアセスメントを実施する必要があります。

評価対象の製品は何か

例示用の架空製品、実在の機器ではありません：ExampleCo CR-12、可搬質量12 kg、リーチ1300 mmの6軸多関節産業用ロボットアーム、力制限の協働モードをオプションで備えます。アーム、コントローラーキャビネット、ティーチペンダント、オプションの2D視覚センサー、プログラミング環境、署名付きOTAアップデート、メーカーフリートクラウドコネクタとともに出荷されます。中小製造業者には完成セルとして、システム統合者にはより大規模な機械のコンポーネントとして販売されます。

この例の製品境界には、アーム、関節駆動、コントローラーキャビネット、安全コントローラー、ペンダント、プログラミングランタイム、OTAサービス、ベンダークラウドコネクタ、脆弱性報告窓口、サポート終了の開示が含まれます。顧客のセルロジック、顧客の安全PLC、工場ネットワーク、サードパーティーのMESまたはSCADA、サードパーティーのエンドエフェクター、フェンスとライトカーテンの設置、AGVまたはAMRベースは含まれません。

この製品は、訓練を受けたオペレーターおよび統合者による屋内産業用途を意図しています。医療または外科ロボット、サービスロボット、教育ロボット、または消費者向け用途は意図していません。

脅威表を書く前に、ロボットのリスクアセスメントを通常駆動する3つの経路、すなわちプログラムロードとペンダント権限、安全とサイバーの境界、統合者引き渡しをテストします。これらの図は、ワークドエグザンプルを汎用の脅威リストではなく工学的問いへと変換します。

製品ファイル記録：5つのステージ記録とN1〜N5のネガティブテスト結果は、メーカーの権限変更タイムラインを構成します。レビュアーが各遷移時点で誰が動作または安全権限を保持していたかを確認できるよう、製品ファイルに保管します。

オーナーシップはプログラムロードとは別個のチェックです。署名付きアップデートを備えたコントローラーであっても、メンテナンス後にサービストンネルが開いたままになっていたり、顧客への移管後も古いエンジニアリングステーションが書き込みを続けていたりすれば失敗します。

フェンス付き産業用ロボットの攻撃面はコボットとどう異なるか

このページでは、両者を同じCRAカテゴリーで扱います。両者ともサイバーレジリエンス層における産業用ロボットであり、スマートホーム製品ではないためです。ただしリスクプロファイルは異なるため、脅威リストはそれを反映すべきです。

ワークドエグザンプルのExampleCo CR-12について、フェンス付き構成では、エンジニアリングステーション権限、リカバリースロットの完全性、廃棄時の認証情報ローテーションを強調します。コボット構成では、視覚入力の認証、キャリブレーションデータの完全性、分離監視の改ざんテスト、オペレーター単位のペンダントロールストアを第一級の関心事として追加します。

保護すべきアセットは何か

ロボットの脅威はすべて同じ事柄に関するわけではないため、リスクアセスメントはアセットから始めます。動作完全性の喪失、安全設定の侵害、エンジニアリングチャネルの乗っ取りは、それぞれ異なる管理策と異なるリリース記録を必要とします。

主な信頼境界はどこか

この例では、メーカーは少なくとも5つの環境をモデル化します。要点は配線をすべて描くことではなく、攻撃者の機会が変わる場所、すなわちキャビネット内、ペンダントリンク上、工場ネットワーク上、メーカーバックエンド、エンジニアリングステーションを分離することです。

安全スタックとサイバースタックは同じプロジェクトではありません。両者は特定の点で証拠を共有しますが、どの条項を誰が所有するかをファイルに明確化する必要があります。

どの脅威を最初に評価すべきか

この例では、製品固有の脅威14件から始めます。要点は網羅性ではなく、メーカーが守るべきトレーサビリティのレベルを示すことです。

次に、統合者引き渡しを別途検討します。誰が結果として生じるセルの製造業者として扱われるか、そしてどの記録がそれとともに移動する必要があるか。

初期リスクをどう順位付けすべきか

すべてのリスクが同じ判断を受けないよう、リリースゲートのはしごを使用します：

どの設計管理策がリスク状況を変えるか

管理策テーブルはR-IDに遡及可能であるべきですが、汎用のセキュア開発チェックリストのように読まれてはなりません。各管理策について、メーカーはこの正確なリリースに対して管理策が存在することを証明するテスト、設計ノート、または運用記録を示せる必要があります。

管理策後にどの残留リスクが残るか

管理策実装後、メーカーは脅威を完了と記すのではなく、アセスメントを再実行すべきです。この例では、サプライヤー脆弱性経路、統合者引き渡し、長期製品寿命が、サポート期間中も能動的に管理され続けます。残留リスクは、監視、トリアージ、署名付きアップデート配信、統合者通知、是正措置のプロセスが実際に運用されていることをメーカーが示せる場合に限り受容可能です。

フリートクラウドアドバイザリーのルーティング

上記のリスクアセスメントは1つのロボットキャビネットで実行されます。アドバイザリールーティングは数百台にわたります。メーカーフリートクラウドが複数の統合者および複数のオペレーターサイトに対応する場合、問いは「クラウドは安全か」ではなく、「24時間の脆弱性警告が発火したとき、チェーン内で誰が聞き、誰が各サイトのアップデートウィンドウを承認するか」です。

リリース記録。 コネクタ一覧上の各統合者およびオペレーターについて、24時間脆弱性警告の窓口、メンテナンスウィンドウ所有者、ロールバック権限者、未解決の残留アドバイザリーを記載したフリートクラウドルーティングマップ。このマップなしでは、期限は不在の受信者を相手に進行します。

リリース前の検証ゲート

汎用の「セキュリティレビュー済み」ゲートは避けてください。ロボット出荷を停止し得る各判断について、障害モード、設計管理策、証拠アーティファクトを伴うリリースゲート目録を1つ使用します。

コンセプトからサポートまでの開発所有権

ロボットが製品定義からライブサポートへと進む中で、主たる所有者は移行します。この導線を使い、製品が変化する各ステージに、主たる担当者、維持される記録、レビューゲートを各1つ割り当てます。

所有権ルール：これはリードチェーンであり、フル責任マトリクスではありません。ロボットが変化する間、各リードが維持される記録を所有します。サポートでの発見事項は次バリアントの境界メモおよび脅威リストにループバックします。

アーキテクチャ作業の前に境界をフリーズし、実装の前に設計意図をフリーズし、検証の前に候補をフリーズし、リリースの前に判断をフリーズし、サポート期間を通じてリリースを稼働させ続けます。受信レポート、サプライヤーアドバイザリー、インシデント結果、回帰結果は、次の境界メモ、脅威リスト、コンポーネントレジスターを再開させます。

ファイルに含める証拠記録

ファイルは、製品アイデンティティからセキュリティ管理策まで、レビュアーがロボットの判断を追跡できるよう構成すべきです。下記の各行は、ばらばらなスクリーンショットのフォルダーではなく、維持される記録を指すべきです。

ロボットSBOMの構成要素

CRAは、製品のコンポーネントを特定し少なくともトップレベル依存をカバーする機械可読のソフトウェア部品表 (SBOM) を要求しますが、現時点で1つの固定フォーマットを指定していません。委員会が詳細を定めるまで、ロボットメーカーは通常CycloneDXまたはSPDXを選択します。SBOMの仕組みに関するクロス製品の詳細は専用のSBOMガイドにあります。本セクションではロボット固有のツリーを扱います。

ロボットリリースは通常、1つのバイナリではなく、別々のアップデートサイクルを持つ複数のデジタル要素を出荷します。CRA最小要件を満たす2つの実装パターンがあります。要素別セクションを備えた1つの製品レベルSBOM（モーションCPU、安全コントローラー、RT OS、ペンダントの各ファームウェアバージョンをピン留め）、または各リリースで更新される出荷デジタル要素ごとの1つのSBOMです。SBOMが機械可読でトップレベル依存がカバーされていれば、いずれのパターンも許容されます。

SBOM記録： CycloneDXまたはSPDXによる、少なくともトップレベル依存をカバーする機械可読SBOM。推奨されるロボットメーカー向けパターン：要素別セクションを備えた1つの製品レベルSBOM、または各リリースで更新される出荷デジタル要素ごとの1つのSBOM。ビルドシステムが生成可能な範囲で、より深い推移的依存も推奨されます。SBOMはコンポーネントアドバイザリー監視記録（証拠マップ行「コンポーネント目録」）と組み合わせ、既知の脆弱性がどのライブラリに該当し、どのリリースで解消されるかをレビュアーが確認できるようにします。

リリース承認の確認項目

ロボットがEU市場向けにリリースされる前に、承認は下のSVGがQ1からQ4と名付ける4つの記録フォルダーを閉じるべきです。ファイル目録の全体は上記の証拠マップにあります。この表はリリースをブロックする4つの問いのみです。

承認ゲート：記録が欠けている場合、リリースは承認されません。

宣言記録： テンプレートおよび必要項目については主要なEU適合宣言書ガイドを使用します。ロボットリリースについては、製品アイデンティティでアーム、コントローラーキャビネット、ペンダント、ファームウェアブランチ、供給オプション、サポート期間への参照を固定すべきです。同じ宣言が機械法令もカバーする場合、そのルートを宣言内に記し、ロボット技術文書と機械安全ファイルを整合させて保管します。

輸入業者、販売業者、統合者、運用者への引き渡し

リリースファイルは、ロボットメーカーから輸入業者、販売業者、製造業者としての統合者、エンドユーザーへの引き渡しを検証可能にすべきです。ロボットおよびコボットの弱点は通常CEマーキングそのものではなく、出荷物、マニュアル、フリートクラウド、OTAサービス、統合者引き渡しが、評価されたリリースと依然として一致しているかどうかです。

引き渡しゲート：パック、トレーサビリティ、サポート表明、フリートクラウド、アップデートチャネル、ロールアイデンティティ、または既知の脆弱性が評価されたリリースと矛盾する場合、ロボットを出荷から掲載に移行させない。

下の行は短縮版です。何を検証するか、いつ一時停止するか、ロボットが新たなロール分析を必要とするのはいつか。クロス製品のロールトリガーの詳細（製造業者、輸入業者、販売業者、認定代理人、オープンソースソフトウェアスチュワード）はCRAの遵守義務を負う者にあります。