こんにちは、マーケティングの宮岡です。
このブログシリーズでは、ものづくりにおける「サイバーセキュリテイ」の、「防御対策」とは別のもう一つの側面である「安全確保」とそれにまつわる話題、およびその実現に必要なテクノロジーやプラットフォームについて解説してきました。今回の最終回では、おさらいとして各回の要旨を再び挙げてみたいと思います。
第1回：IoT 製品開発におけるサイバーセキュリティへの取り組み
IoT 製品はソフトウエアをアップデートすることで、機能や性能を向上させることができるという特徴を持ちます。しかし、ソフトウエアのアップデートが実施されても安全に利用できるような手段を講じなければいけません。ソフトウエアをアップデートして機能を更新する場合、最新の機器の仕様だけでなく、関係するすべての世代にわたって変更による影響を検討する必要があります。IoT 製品では、出荷時の品質を保障するだけでなく、出荷後もユーザが利用している限り継続して品質を担保できるような仕組みが必要です。これからの製品開発を考える場合、製品の安心・安全を担保するためには、新たにサイバーセキュリティへの取り組みが必要となってきます。
ーーーーー
国連自動車基準調和世界フォーラム（以下 WP29）では、サイバーセキュリティ対策として、意図しない不正なソフトウエアの改竄、なりすましによる乗っ取り、攻撃によるシステムダウンなど、走る・曲がる・止まるに係わる自動車の重要機能に影響するリスクを低減すると共に、リスクが顕在化した場合でも安全に止まる等の制御が行える様にする事を目指しており、サイバーセキュリティに関するマネジメントシステム（CSMS）要件と合わせ、ソフトウエアアップデートのマネジメントシステム（SUMS）にも言及し、ソフトウエアアップデートにおける影響度分析やバージョン管理およびセキュリティ対策についても検討され国際規格 ISO/SAE 21434 として制定が進められています。
自動車情報共有・分析センター（Auto-ISAC）では、インシデント対応やリスク評価と管理、脅威の検出と監視と合わせて、セキュリティ開発ライフサイクル（SDL：Security Development Lifecycle）として製品開発プロセスにおけるハードウエアとソフトウエアのサイバ―セキュリティ機能の統合に関する取り組みにも触れられています。変更による影響を正確に把握し、正しいバージョンの製品に対し、適切な設計変更を実施できる事が必要で、そのためには製品情報のバージョン管理や影響分析、関連する設計情報を簡単に見つけ活用できるようにするには、SDL データを管理するための基盤（プラットフォーム）が必要です。
ーーーーー
サイバー攻撃は日々進化しています。今日の対策が明日も有効であるという保証はありません。日々進化するサイバー攻撃に対する監視を継続すると共に、常に最新の対策が組み込める運用とアーキテクチャを設計することが IoT 製品には求められます。
設計変更を正しく実施するには、該当する対象製品に対し、正確に影響を把握し、適切な変更を加える必要があります。しかし設計の現場では、設計情報は分散し個別に管理されていたり、フォルダや SharePoint を使った共有管理が大半を占めます。PDM や PLM を導入しているほとんどの会社では、部門別・グループ別にサイロ化されたデータを管理する用途にとどまっています。メカ・エレ・ソフトの情報がサイロ化されたデータベースに分散されて管理されている状態は、IoT 製品にとっては設計情報がファイル管理されているのと同様です。IoT 製品においては、デジタルツインを用いサイバーセキュリティの影響を事前に把握し、デジタルスレッドを活用して正しく変更が実施できるような製品情報管理が求められます。
ーーーーー
IoT 製品の情報を管理するアーキテクチャとしてはツールとしての視点とプラットフォームという両方からの観点で考えていく必要があります。日々進化するサイバー攻撃への対策は、部品化・ツール化して常に最新のモノに置き換えられるように設計する必要があります。また特定の製品の機能として個別に特化するのではなく、どの製品にも適用可能なように共通化してデザインすることも必要です。一方、ソフトウエアアップデートプロセスなど安全を維持する活動は、業務プロセスと同期をとる必要があります。業務プロセスは常に変化しているため、製品情報を管理するプラットフォームも業務プロセスの変化に対応できる必要があります。
サイバーセキュリティを考慮した IoT 製品の開発プロセスをデザインする場合、「表の仕事」と「裏の仕事」を意識して業務プロセスをデザインしていくと良いでしょう。「表の仕事」とはメインで行う設計作業のことを指します。一方「裏の仕事」とは、不具合対策や設計変更を実施する場合など、元の仕様がどうだったのか？ どのような意図で検討されたのか？ なぜそのような機能になったのか？ など過去の情報を遡って行われる調査などが挙げられます。サイバーセキュリティのマネジメントを実現する場合、「表の仕事」を通して作成されたデジタルデータが集まってデジタルツインとして構成される時に、情報の糸（意図や関連性）としてデジタルスレッドも作成されるような仕掛けを施しておきます。こうしておけば、デジタルスレッドを使って時間軸を逆に辿ることで必要な情報を簡単に集めることができるようになります。このような仕掛けを IT プラットフォームとして実現することで、サイバーセキュリティに関する “防衛” と “安全保障” を維持するためのマネジメントインフラを整えることができます。
ーーーーー
サイバーセキュリティのバリデーションを考える場合、“脅威に対する防衛” に対してだけでなく、“製品の安全保障” に関しても実際に試作品を作成するのではなく、デジタルツインを活用してテストや検証を進めるのが効率的です。しかしその一方、デジタルツインプロジェクトの多くがパイロットフェーズ止まりになっている原因の一つとして、3D データ = デジタルツインと限定して取り組んでいることが挙げられています。
デジタルツインとは、実際に稼働している製品に関わるデジタル情報のことを言います。この中には機械的な情報だけでなく、電気/電子的な情報およびソフトウエアに関する情報なども含まれています。3D データは部品表で管理されている一要素でしかありません。部品表には 3D データだけでなく、要求事項や解析結果、製品スペックなどが関連づき管理されています。部品表は設計段階の製品構成（部品表）だけでなく、構想段階の製品構成や生産段階の構成、運用時の構成など、製品のライフサイクルにわたっていくつかの異なる形体を持ちます。
ソフトウエアアップデートにおけるサイバーセキュリティのバリデーションを行うには、ソフトウエアの変更と連動して変化するデジタルツインが持つパラメータ値を追いかけ、製品安全が保障できるのかを判断したり、セキュリティホールからの攻撃シミュレーションを行い、パラメータが閾値を超えるのかを見てリスクを判断していきます。
この時、製品構成や 3D データ、諸元値および客先での導入構成や工場出荷時の製品構成、企画と要求事項など、対象となる製品に関わる様々な情報を集める必要がありますが、これらの情報を繋ぐデジタルの仕組みを “デジタルスレッド” と呼んでいます。
ーーーーー
制御システムには MILS、SILS、HILS といわれるシミュレーション手法が用いられています。
- MILS (Model In the Loop Simulation) : 制御の振る舞いをモデルとして定義し、制御モデルの処理内容に関する妥当性検証を行う方法
- SILS (Software In the Loop Simulation)：モデルから生成されたプログラムコード(ソフトウエア）を使って制御ユニットの動作検証を行う方法
- HILS (Hardware In the Loop Simulation)：制御ユニットとして実際のハードウエアを使って制御対象の動作シミュレーションを行い検証する方法
サイバーセキュリティにおけるソフトウエアアップデートの際にも、様々な条件で制御システムの動作を事前にシミュレーションして検証しておくことは、製品の安全保障を実現するうえで欠かせません。
デジタルツインとは現実世界のモノをデジタルで表現した双子で、デジタルの双子としてのデータはユーザの手元にある製品情報がベースになります。一方 MILS や SILS、HILS は制御システムを対象としたシミュレーションです。例えば、タービンの故障に関わる予兆を検知し、予防保全を図り稼働率を向上させていくために、デジタルツインの “なんとか In the Loop” を実現するには、制御システムのシミュレーションだけでなく、制御と連動して動くハードウエアや IoT 製品の設置状態および環境の変化なども併せて連成でシミュレーションされていくことが望まれます。
自動運転などデジタルツインを使ってシミュレーションする場合、センサーやソフトウエアなどの動作を確認する単機能のシミュレーションおよびそれらを組み合わせたシステムレベルのシミュレーションと合わせ、利用環境を想定したシナリオが重要になってきます。それは、意図した機能における安全性だけでなく、想定外の攻撃による被害のシナリオから影響度の評価を行い、安全が保障されるシナリオも含めることが望まれます。
ーーーーー
製品設計の流れは、ハイレベルな要求事項の定義から始まり、機能として具体化し、ロジックに分解され、具体的な図面に落とし込むといった形で製品情報を具現化していきます。具現化された設計情報は部品として作られ、最終的には製品として組立られていきます。製品開発の流れは、構想を詳細化する流れと、それを具現化する流れが相対するポジションにあるため、開発プロセスの全体像をアルファベットのＶ（ヴイ）にたとえてＶ字開発プロセスと呼ばれています。試作回数を減らしつつ製品品質を向上するには、詳細化された設計情報が試作品として実体化する前に、機能ロジックや図面化されたデジタルデータを元にシミュレーションを行い、設計段階での品質の作りこみを実現していきます。
サイバ―セキュリティマネジメントシステム（CSMS）を考える場合、データがサイロ化されることを未然に防ぎ、設計のライフサイクルにわたって情報が共有できるような仕組み、すなわちデジタルスレッドが求められます。
還元主義的になりがちな設計情報の管理基盤に、デジタルスレッドの仕組みが組み込まれていることにより、着眼大局的に情報が管理されシステムズシンキングの枠組みを維持することが可能となります。設計情報のデジタルスレッドは、要求 (R) とテスト結果 (T/V&V) をつなげるだけでなく、機能化 (F)、ロジック化 (L)、物理化 (P) に細分化されていく垂直方向の各階層間もつながっていきます。設計データをデモクラタイズし、製品ライフサイクルの様々な工程で自由に活用できる様にするために、CSMS/SUMS には、システムズシンキングを取り入れた情報管理プラットフォームのアーキテクチャ設計が求められます。
ーーーーー
Single Source of Truth（SSOT）とは、分散管理されているデータに対し、ユーザはあたかも一つのソースの様にアクセスできるデータスキーマを表現する言葉で、主に ESB（Enterprise Service Bus）や MDM（Master Data Management）および DWH（Data Warehouse）などのミドルウエアなどの EA フレームワークとして使われている言葉です。SSOT を実現することにより、組織内の利用ユーザ全員が「信頼できる同一の情報源（Single Source of Truth）」へのアクセスを可能にします。
CSMS/SUMS プロセスにおいても、サイロ化され、分散管理されている設計情報に対して Single Source of Truth でアクセスし、正しい情報を取得できることが望まれます。この場合、単にサイロ化データを一元管理できるスキーマを持つデータベースを実現しても意味はなく、各設計情報が持つ意図やコンテキストを踏まえ、セキュアに欲しい情報をピンポイントで探し出すことができる Single Source of Truth の仕組みが求められます。
Single Source of Truth の各リソースをデジタルスレッドを使ってつなぎ、サイロ化されたソースをデモクラタイズすることで、ドメインをまたがる作業者同士が信頼できる同一の情報源を使って作業を進められることできます。これにより、正しい意思決定が可能となり、設計の手戻りや情報を見つけるための無駄な作業を省き、コミュニケーションの向上、設計期間を短期化、品質向上を実現します。
ーーーーー
150% BOM とは、ATO（Assemble To Order）や ETO（Engineering To Order）などの個別受注製品のバリアント BOM に対して使われている言葉です。ATO の場合は互換性や組合せの種類を、ETO の場合はカスタム要件およびオプションやカスタマイズ可能な部品の組み合わせを、バリアントとして BOM に持たせ 150% BOM として構築します。そこに準備し受注した仕様を入力すると、ルールに応じて必要な部品の組み合わせが抽出され、製造可能な製品構成が 100% BOM として作成されます。
設計領域で 150% BOM という言葉が使われ始めた背景には、自動運転や IoT 製品など、メカ、エレ、ソフトが密接に関係する製品開発において、MBSE（Model Based Systems Engineering）手法を用いてプロダクトラインを俯瞰する製品アーキテクチャの設計から始めることが多くなったことが挙げられます。
部品の共通化はソフトウエアの世界にも浸透してきています。ソフトウエアの世界の PLE（プロダクトラインエンジニアリング）では、再利用を前提に共通化するコアのプログラムを設計したのちに、様々なアプリケーションでコアプログラムの流用を行います。既存のプログラムを流用する派生開発と区別し、SPLE（ソフトウエアプロダクトラインエンジニアリング）開発と呼ばれたりしています。コアプログラムを含めた機能を 150% BOM として統合管理し、仕様に合わせて必要なプログラム機能を選択し、抽出された 100% BOM を使ってソフトウエアのアーキテクチャを設計する場合などに使われています。
このように PLE や派生、シリーズ製品の開発を進めるに際し部品が共有可能かを判断するために、機能に関する情報だけでなく、当該機能を採用するに至ったそもそもの仕様に関する要求事項や目的にまでさかのぼって情報を共有することが重要です。サイバーセキュリティにおけるソフトウエアアップデートを安全に実施するためには 150% BOM を整備し、プロダクトラインにまたがるソフトウエアの変更を安全かつ効率的に実施できる環境が求められています。
最後までお読みいただき、ありがとうございました。改めて各回のブログを見返していただき、皆さまの業務効率・改革にお役立ていただければ幸いです。
「ものづくりにおける“サイバーセキュリティ”」ブログシリーズ 目次
第0回：ものづくりにおける「サイバーセキュリティ」とは？ ～イントロダクション～
第1回：IoT製品開発におけるサイバーセキュリティへの取り組み
第2回：自動車におけるサイバーセキュリティ
第3回：サイバーセキュリティのマネジメント
第4回：サイバーセキュリティのマネジメント（その２）
第5回：サイバーセキュリティにおけるデジタルツイン
第6回：なんとか In the Loop
第7回：着眼大局
第8回：Single Source of Truth
第9回：150% BOM
最終回：ものづくりにおける「サイバーセキュリティ」とは？ 〜おさらい〜