Masahiko Hisatsugu さんのアクティビティ

【CSMS第9回】150% BOM

Masahiko Hisatsugu — Fri, 07 Aug 2020 03:00:00 GMT

アラスジャパンの久次です。

ものづくりにおける“サイバーセキュリティ”のブログシリーズ第9回として、今回は150% BOMの活用について触れてみたいと思います。

150% BOM

150% BOMとは、ATO(Assemble To Order)やETO(Engineering To Order)などの個別受注製品のバリアントBOMに対して使われている言葉です。ATOの場合は互換性や組合せの種類を、ETOの場合はカスタム要件及びオプションやカスタマイズ可能な部品の組み合わせを、バリアントとしてBOMに持たせ150% BOMとして構築します。
製造可能な組み合わせを150% BOMとして、準備し受注した仕様を入力すると、ルールに応じて必要な部品の組み合わせが抽出され、製造可能な製品構成が100% BOMとして作成されます。

150% BOM : 互換性やオプション及び組合せ条件などを含めた、構成することが可能（Configurable）なBOM
100% BOM : 受注条件や仕様に合わせて構成済み(Configureed)のBOM

従来は、個別受注生産における工場で組立に必要な部品構成（BOM)を指示する仕組みとして使われていましたが、最近では設計開発の領域にも使われ始めています。

プロダクト・ライン・エンジニアリング：PLE

製品開発では、開発した機能や資産を有効活用するため、派生機種やシリーズ製品の開発を行う事がよくあります。派生機種やシリーズ製品の設計では、開発済みのコア機能や共通ユニットはそのままに、様々なオプションを付加することで製品バリエーションを増やし、市場における製品の付加価値を向上させたり、開発期間やコストの削減を行うことが出来ます。
この様な開発手法はシリーズ製品開発やプロダクトラインエンジニアリング（PLE)と呼ばれており、プロダクトラインを跨いで共有して使われる部品の情報を統合管理するため150% BOMが使われています。特徴のあるコア機能や実績のある共通ユニットなど、再利用可能な機能を使いまわすことで開発期間の短縮やコスト削減ができるだけでなく、トレーサビリティを確保しメンテナンス性の向上を実現することも可能です。

設計領域で150% BOMという言葉が使われ始めた背景には、自動運転やIoT製品など、メカ、エレ、ソフトが密接に関係する製品開発において、MBSE(Model Based Systems Engineering)手法を用いてプロダクトラインを俯瞰する製品アーキテクチャの設計から始めることが多くなったことが挙げられます。自動車のスイッチやリモコン、アクチュエーターなど見た目は少し異なっているが機能などは共有化されているものが多数存在ます。流用されているコア機能や共通部品の設計変更を行う場合、担当している機種だけでなく派生機種への影響も考慮しなければなりません。派生機種やシリーズ製品へのトレーサビリティを確保し、影響度を把握できるようにするには150% BOMを活用するのが有効です。

ソフトウエア・プロダクト・ライン・エンジニアリング : SPLE

部品の共通化はソフトウエアの世界にも浸透してきています。ソフトウエアの世界のPLEでは、再利用を前提に共通化するコアのプログラムを設計したのちに、様々なアプリケーションでコアプログラムの流用を行います。既存のプログラムを流用をする派生開発と区別し、SPLE（ソフトウエアプロダクトラインエンジニアリング）開発と呼ばれたりしています。コアプログラムを含めた機能を150% BOMとして統合管理し、仕様に合わせて必要なプログラム機能を選択し、抽出された100% BOMを使ってソフトウエアのアーキテクチャを設計する場合などに使われています。ソフトウエア開発の世界でも150% BOMが重要になってきた背景には、車載電子システムの機能安全規格 ISO26262における電子システムに対する安全上のリスク回避や低減、ISO/SAE 21434のCSMS/SUMSにおけるソフトウエアの安全性確保が喫緊の課題として注目が集まり、仕様変更時における影響度を正しく判断し、不具合発生リスクを抑えることが求められているという背景があります。

要求事項や設計意図を知る

この様にPLEや派生、シリーズ製品の開発を進めるに際し部品が共有可能かを判断するために、機能に関する情報だけでなく、当該機能を採用するに至ったそもそもの仕様に関する要求事項や目的にまでさかのぼって情報を共有することが重要です。機能に関する記述だけでは共通化ポイントを見つけることが難しいだけでなく、変更における影響度などを判断する為に、要求事項までさかのぼり、仕様決定にまつわる意図が理解できれば、共通化の切り分けや変更への影響などを理解しやすいという事が分かってきました。サイバーセキュリティにおけるソフトウエアアップデートを安全に実施するためには150% BOMを整備し、プロダクトラインにまたがるソフトウエアの変更を安全かつ効率的に実施できる環境が求められています。

*注：150% BOMや100% BOMだけでなく120% BOMなんて言葉も出てきています。100% BOMが実際に組立可能なの製品構成を表すのに対し、120% BOMは同一製品内のバリエーションの選択肢を含むBOM、150% BOMがプロダクトラインを跨ぐオプションを含めたBOMと考えると良いでしょう。

【CSMS第8回】Single Source of Truth

Masahiko Hisatsugu — Fri, 31 Jul 2020 03:00:00 GMT

アラスジャパンの久次です。

ものづくりにおける“サイバーセキュリティ”のブログシリーズ第８回として、今回は”Single Source of Truth”というタイトルで、情報を一元管理するアーキテクチャについて考えてみたいと思います。

Single Source Of Truth (SSOT)とは、分散管理されているデータに対し、ユーザはあたかも一つのソースの様にアクセスできるデータスキーマを表現する言葉で、主にESB(Enterprise Service Bus)やMDM(Master Data Management)及びDWH（Data WareHouse)などのミドルウエアなどのEAフレームワークとして使われている言葉です。
SSOTを実現することにより、組織内の利用ユーザ全員が”信頼できる同一の情報源”（Shingle Source of Truth)へのアクセスを可能にします。

ビジネスアプリケーションにおけるSingle Source of Truth

SlackやMS TeamsなどのビジネスSNSの普及やPLMの定着に伴い、共同作業における同一ソースを使った効率性の理解が進み、今日ではビジネスアプリケーションの世界でも使われ始めています。

メカトロニクス、エレクトロニクス及びソフトウエアの開発作業が密接に並行して進められるIoT製品の開発において、各部門を超え設計情報を共有することは作業の効率化だけでなく、品質向上を実現する上でも重要なテーマです。還元主義的に専門分野に分かれて作成される設計成果物は、おのずと情報のサイロ化に陥りがちです。しかし、繰り返し変更が発生しスパイラルに進む設計作業に於いて、他のチームの成果物と整合を取ることは、協業作業の効率化を図り設計品質を向上させるためには欠かせません。

CSMS/SUMSプロセスにおいても、サイロ化され、分散管理されている設計情報に対してSingle Source of Truthでアクセスし、正しい情報を取得できることが望まれます。この場合、単にサイロ化データを一元管理できるスキーマを持つデータベースを実現しても意味は無く、各設計情報が持つ意図やコンテキストを踏まえ、セキュアに欲しい情報をピンポイントで探し出すことができるSingle Source of Truthの仕組みが求められます。

Single Source Of Truthの要件

CSMS/SUMSをはじめとするコラボレーション設計に求められるSingle Source of Truthの要件として、下記のことが挙げられます。

- コンテキストに沿て正しく一意のデータにアクセス可能である事
製品開発の現場では、時や場所及び状況が異なっていても、コンテキストに沿って正しく同一の情報源(Single Source)に辿り着くことが求められます。
例えば製品の不具合や、歩留まりの悪化、原価の上昇が同じ設計変更に起因している場合があります。情報にアクセスする立場が変わっても、同一の情報源に行きつける仕組みが必要です。ソースはテキストデータだけではありません。画像や3Dデータ及びNoSQLなどの非リレーショナルなデータなども、関係するソースとし取り出せる必要があります。

- データは参照だけでなく更新も可能で有る事
様々な情報ソースにコンテキストに沿って一意のデータにアクセスするだけで有れば、インターネットのハイパーリンクの機能で十分です。しかし製品開発の場合、メカ・エレ・ソフトの開発はそれぞれ個別に進められ成果物は作成されますが、全ての情報は開発対象の製品軸で統合されソースに反映されている必要があります。分散し、個別に進められている異なるフォーマットの成果物データが、製品軸で統合され共通の同一のソースに世代別に管理できる仕組みを作ることで、情報の鮮度を常に維持することが可能となります。

- ソースの追加・変更が容易である事
Single Source of Truthを実現するために、一つのアプリケーションで全てのデータを管理することは現実的ではありません。必要とされるソースは常に変化します。そのたびに他システムとのインターフェースを構築することも現実的ではありません。変化するソースに柔軟に対応できるように、システム間をフェデレーションで連携したり、データ構造をマッピングだけで簡単に変更可能な仕組みを整えておく必要があります。

- 柔軟なアクセスコントロールが適用できる事
分散されたソースにSSOTでアクセスできる環境では、関係のない人が不用意にデータにアクセスできなくする為のアクセスコントロール機能が必須です。アクセスコントロールもデータや人、組織へのアクセスコントロール（ACL)だけでなく、ロールベースのアクセスコントロール（RBAC)、データの属性を使ったアクセスコントロール（ABAC)や人の移動にも柔軟に対応可能なドメインベースのアクセスコントロール（DBAC)など、業務の粒度に応じ様々なレベルのアクセスコントロール機能が求められます。

- トレーサビリティが行えること
SSOT環境を使って複数の人が共同で作業を進め場合、時間軸に沿ってデータ履歴が追えるだけでなく、関連するデータを逆展開して設計意図や当初の目標などを確認できれば、作業者間の情報連携を密にし、手戻りを防ぎ作業効率を図ることが出来ます。
情報のトレーサビリティを実現する際には、変更によるソースの差異を把握できる仕組みも、作業の効率を図る為には求められてきます。

デジタルスレッドで繋ぐSSOT

メカ・エレ・ソフトのチームが協調して作業を進めるソフトウエアのアップデート開発では、ドメインを跨いだエンジニア間の情報共有は必須です。簡単な検索キーワードを使って必要な情報を見つけられるインターネットの様な仕組みが、CSMS/SUMSのエンジニアリング環境にも必要ですが、インターネットと同じ様に無数のWebサイトと、それを検索する為の強力な検索エンジンを企業内に構築することは無理があります。
しかし、信頼できる情報源をデジタルスレッドで繋ぎ、キーワードや形状での検索、またはリレーションを辿ることで、インターネットにおけるハイパーリンクと同様の仕組みを実現することが出来ます。
Single Source of Truthの各リソースをデジタルスレッドを使ってつなぎ、サイロ化されたソースをデモクラタイズすることで、ドメインをまたがる作業者同士が信頼できる同一の情報源を使って作業を進められることできます。これにより、正しい意思決定が可能となり、設計の手戻りや情報を見つけるための無駄な作業を省き、コミュニケーションの向上、設計期間を短期化、品質向上を実現します。

【CSMS第7回】着眼大局

Masahiko Hisatsugu — Fri, 24 Jul 2020 03:00:00 GMT

アラスジャパンの久次です。

今回は、ものづくりにおける“サイバーセキュリティ”のブログシリーズ第7回として、着眼大局というタイトルでシステムズシンキングについて考えてみたいと思います。

製品設計の流れは、ハイレベルな要求事項の定義から始まり、機能として具体化し、ロジックに分解され、具体的な図面に落とし込むといった形で製品情報を具現化していきます。具現化された設計情報は部品として作られ、最終的には製品として組立られていきます。製品開発の流れは、構想を詳細化する流れと、それを具現化する流れが相対するポジションにあるため、開発プロセスの全体像をアルファベットのV（ヴイ）にたとえV字開発プロセスと呼ばれています。試作回数を減らしつつ製品品質を向上するには、詳細化された設計情報が試作品として実体化する前に、機能ロジックや図面化されたデジタルデータを元にシミュレーションを行い、設計段階での品質の作りこみを実現していきます。

図：モノづくりのV字

システムズシンキング

メカ・エレ・ソフトが密に連動するIoT製品も、着眼大局でシステムのアーキテクチャをとらえ機能を具現化していく必要があり、俯瞰した視点でアーキテクチャ設計を進める方法をシステムズシンキングと呼んでいます。

機能化(F)、ロジック化(L)、物理化(P)と設計作業が進むとテーマが細分化され還元主義的（Reductionism)になり、データがサイロ化されて行きます。サイバ―セキュリティマネジメントシステム（CSMS)を考える場合、データがサイロ化されることを未然に防ぎ、設計のライフサイクルに亘って情報が共有できるような仕組みが求められます。
システムズシンキングを用いたモノづくりのプロセスでは、設計要件をそれぞれ、機能化(F)レイヤー、ロジック化(L)レイヤー、物理化(P)レイヤーにおける各ステージの作業と紐づけ、設計要件(R)をインプットとし、テスト(T)やシミュレーション結果(V&V)をアウトプットとして関連づけることで、設計要求とその実現案に対するトレーサビリティを実現していきます。

図：システムズ視点で見るモノづくりのV字

より良い答えを見つけるため設計作業はスパイラルに繰返し行われるため、成果物も随時改定されます。何世代にも分かれる成果物を正しく管理するにはデジタルスレッドが大いに役に立ちます。
成果物のトレーサビリティは、最新のバージョンを追えば良いというわけではありません。メタデータをつなげるデジタルスレッドを使えば、正しいバージョンのデータを簡単に見つけることが出来ます。デジタルスレッドはインターネットの世界のハイパーリンクと同様の働きをし、必要な情報に辿り着くための道先案内の役割を果たします。

活きた情報”プロパティ”

モノづくりにおけるV字モデルのトレーサビリティでは、プロパティも重要な役割を持ちます。たとえば、製品の要求事項として、スペック、稼働環境やコスト及び重量などが設計目標として定義されます。稼働環境としてセンサーの動作保証を-25℃から＋75℃までと設定した場合、-25や+75と表現されている値（プロパティ）の"25"や"プラス"及び"マイナス"は単なる文字列以上の意味を持ちます。稼働環境の検討を重ねていく中で、仕様説明の大半は同じ文言で固定化されていきますが、温度などの数値は最適な値を見つけるため設計を進めるたびに上下し、-10℃になったり-30℃になったり常に変わっていきます。この変更点の差異を正しく設計の後工程に伝える必要があり、これらの数値（プロパティ）はシミュレーションやテストなどにも活用されていくため、活きた情報として関連するチームに伝える必要があります。
デジタルスレッドをCSMSに組み込む場合、データのつながりだけでなく、プロパティを活かすデジタルスレッドのアーキテクチャ設計を心掛けると良いでしょう。

システムズシンキングやデジタルスレッド及びデジタルスレッドにおけるプロパティの役割をわかりやすく紹介しているビデオがあるので参考にしてください。
The Digital Thread in Action - Systems Thinking for Digital Transformation

システムズシンキング　vs　還元主義

還元主義的になりがちな設計情報の管理基盤に、デジタルスレッドの仕組みが組み込まれていることにより、着眼大局的に情報が管理されシステムズシンキングの枠組みを維持することが可能となります。
設計情報がF、L、Pに細分化されていく仕事の流れでは、前工程の成果物が次工程のインプットとして繋がっています。もちろん前工程の成果物は常に改定がかかるため、改定された前工程のアウトプットは正しく次工程のインプット情報と関連づけられる必要があります。設計情報のデジタルスレッドは、要求(R)とテスト結果(T/V&V)をつなげるだけでなく、機能化(F)、ロジック化(L)、物理化(P)に細分化されていく垂直方向の各階層間もつながっていきます。設計データをデモクラタイズし、製品ライフサイクルの様々な工程で自由に活用できる様にするために、CSMS/SUMSには、システムズシンキングを取り入れた情報管理プラットフォームのアーキテクチャ設計が求められます。

【CSMS第7回】着眼大局

Masahiko Hisatsugu — Fri, 24 Jul 2020 03:00:00 GMT

アラスジャパンの久次です。

図：モノづくりのV字

システムズシンキング

図：システムズ視点で見るモノづくりのV字

活きた情報”プロパティ”

システムズシンキング　vs　還元主義

【CSMS第6回】なんとか In the Loop

Masahiko Hisatsugu — Fri, 17 Jul 2020 10:11:00 GMT

アラスジャパンの久次です。

ものづくりにおける“サイバーセキュリティ”のブログシリーズ第6回として、今回はデジタルツインのシミュレーションについて触れてみたいと思います。

制御システムにはMILS、SILS、HILSといわれるシミュレーション手法が用いられています。

MILS(Model In the Loop Shimulation) : 制御の振る舞いをモデルとして定義し、制御モデルの処理内容に関する妥当性検証を行う方法
SILS(Software In the Loop Simulation)：モデルから生成されたプログラムコード(ソフトウエア）を使って制御ユニットの動作検証を行う方法
HILS(Hardware In the Loop Simulation)：制御ユニットとして実際のハードウエアを使って制御対象の動作シミュレーションを行い検証する方法

これ以外にもPILS(Processor In the Loop Simulation)、CILS(Componet In the Loop Simulation)、VILS(Vircle In the Loop Simulation)など、シミュレーションする範囲や対象に応じた手法が確立されています。

サイバーセキュリティにおけるソフトウエアアップデートの際にも、様々な条件で制御システムの動作を事前にシミュレーションして検証しておくことは、製品の安全保障を実現するうえで欠かせません。

デジタルツインの”なんとか In the Loop”

デジタルツインを使ったシミュレーションも"なんとか In the Loop"という手法がとられるのでしょうか？デジタルツインとは現実世界のモノをデジタルで表現した双子で、デジタルの双子としてのデータはユーザの手元にある製品情報がベースになります。一方MILSやSILS、HILSは制御システムを対象としたシミュレーションです。タービンの故障に関わる予兆を検知し、予防保全を図り稼働率を向上させていく為に、デジタルツインの”なんとか In the Loop”を実現するには、制御システムのシミュレーションだけでなく、制御と連動して動くハードウエアやIoT製品の設置状態及び環境の変化なども併せて連成でシミュレーションされていくことが望まれます。

安全性が最重要テーマとなるクルマの自動運転では、時々刻々と変化する走行環境を再現し、複数のシミュレーションを連成して実施し、ドライバーが予見できない事象に関しても事前にシミュレーションして問題点を洗い出す取り組みが始まっています。
　
<出典:ANSYSホームページより>

一般的に解析業務は専門特化された業務であるため、解析データは個別に管理されていく傾向にあります。現実の世界に近い結果を得るには一つの物理現象に対するシミュレーションだけでなく、複数の物理事象や現象を連成で解析（マルチフィジックス）する必要が出てきます。ANSYSにおけるBMWの事例の様に、縦割りにサイロ化された解析データをデモクラタイズ＊し、パラーメータやデータフローのプロセスと合わせて管理できるようにすることで、マルチフィジックス解析を実現してより現実の物理事象に近いシミュ―レーション結果を得る取り組みが始まっています。
＊デモクラタイズ：サイロ化され個別管理さているデータを誰からもアクセスできるようにする取り組みを民主化になぞらえデモクラタイズと呼んでいます。

既知のリスクと未知のリスク

自動運転などデジタルツインを使ってシミュレーションする場合、センサーやソフトウエアなどの動作を確認する単機能のシミュレーション及びそれらを組み合わせたシステムレベルのシミュレーションと合わせ、利用環境を想定したシナリオが重要になってきます。
シナリオとしては、自動運転におけるSOTIF（SAFETY OF THE INTENDED FUNCTIONALITY）規格で要求されている意図した機能における安全性だけでなく、想定外の攻撃による被害のシナリオから影響度の評価を行い、安全が保障されるシナリオも含める事が望まれます。

デジタルツインを使ったシミュレーションを行いリスクを特定し影響を評価するには、モノづくりのV字プロセスを遡って原因の分析と対策を検討するといった進め方になります。
この時、シミュレーション結果からデジタルスレッドを使って関連する情報を特定できるようにしておくことで、サイバ―セキュリティにおけるリスク対策を効率的に実施することが可能となります。

次回の記事もぜひお読みください。

【CSMS第6回】なんとか In the Loop

Masahiko Hisatsugu — Fri, 17 Jul 2020 03:00:00 GMT

アラスジャパンの久次です。

制御システムにはMILS、SILS、HILSといわれるシミュレーション手法が用いられています。

MILS(Model In the Loop Shimulation) : 制御の振る舞いをモデルとして定義し、制御モデルの処理内容に関する妥当性検証を行う方法
SILS(Software In the Loop Simulation)：モデルから生成されたプログラムコード(ソフトウエア）を使って制御ユニットの動作検証を行う方法
HILS(Hardware In the Loop Simulation)：制御ユニットとして実際のハードウエアを使って制御対象の動作シミュレーションを行い検証する方法

デジタルツインの”なんとか In the Loop”

既知のリスクと未知のリスク

次回の記事もぜひお読みください。

【CSMS第6回】なんとか In the Loop

Masahiko Hisatsugu — Fri, 17 Jul 2020 03:00:00 GMT

アラスジャパンの久次です。

制御システムにはMILS、SILS、HILSといわれるシミュレーション手法が用いられています。

MILS(Model In the Loop Shimulation) : 制御の振る舞いをモデルとして定義し、制御モデルの処理内容に関する妥当性検証を行う方法
SILS(Software In the Loop Simulation)：モデルから生成されたプログラムコード(ソフトウエア）を使って制御ユニットの動作検証を行う方法
HILS(Hardware In the Loop Simulation)：制御ユニットとして実際のハードウエアを使って制御対象の動作シミュレーションを行い検証する方法

デジタルツインの”なんとか In the Loop”

既知のリスクと未知のリスク

次回の記事もぜひお読みください。

【CSMS第6回】なんとか In the Loop

Masahiko Hisatsugu — Fri, 17 Jul 2020 03:00:00 GMT

アラスジャパンの久次です。

制御システムにはMILS、SILS、HILSといわれるシミュレーション手法が用いられています。

MILS(Model In the Loop Shimulation) : 制御の振る舞いをモデルとして定義し、制御モデルの処理内容に関する妥当性検証を行う方法
SILS(Software In the Loop Simulation)：モデルから生成されたプログラムコード(ソフトウエア）を使って制御ユニットの動作検証を行う方法
HILS(Hardware In the Loop Simulation)：制御ユニットとして実際のハードウエアを使って制御対象の動作シミュレーションを行い検証する方法

デジタルツインの”なんとか In the Loop”

既知のリスクと未知のリスク

次回の記事もぜひお読みください。

【CSMS第6回】なんとか In the Loop

Masahiko Hisatsugu — Fri, 17 Jul 2020 03:00:00 GMT

アラスジャパンの久次です。

制御システムにはMILS、SILS、HILSといわれるシミュレーション手法が用いられています。

MILS(Model In the Loop Shimulation) : 制御の振る舞いをモデルとして定義し、制御モデルの処理内容に関する妥当性検証を行う方法
SILS(Software In the Loop Simulation)：モデルから生成されたプログラムコード(ソフトウエア）を使って制御ユニットの動作検証を行う方法
HILS(Hardware In the Loop Simulation)：制御ユニットとして実際のハードウエアを使って制御対象の動作シミュレーションを行い検証する方法

デジタルツインの”なんとか In the Loop”

既知のリスクと未知のリスク

次回の記事もぜひお読みください。

【CSMS第6回】なんとか In the Loop

Masahiko Hisatsugu — Fri, 17 Jul 2020 03:00:00 GMT

アラスジャパンの久次です。

制御システムにはMILS、SILS、HILSといわれるシミュレーション手法が用いられています。

MILS(Model In the Loop Shimulation) : 制御の振る舞いをモデルとして定義し、制御モデルの処理内容に関する妥当性検証を行う方法
SILS(Software In the Loop Simulation)：モデルから生成されたプログラムコード(ソフトウエア）を使って制御ユニットの動作検証を行う方法
HILS(Hardware In the Loop Simulation)：制御ユニットとして実際のハードウエアを使って制御対象の動作シミュレーションを行い検証する方法

デジタルツインの”なんとか In the Loop”

既知のリスクと未知のリスク

次回の記事もぜひお読みください。

【CSMS第6回】なんとか In the Loop

Masahiko Hisatsugu — Fri, 17 Jul 2020 03:00:00 GMT

アラスジャパンの久次です。

制御システムにはMILS、SILS、HILSといわれるシミュレーション手法が用いられています。

MILS(Model In the Loop Shimulation) : 制御の振る舞いをモデルとして定義し、制御モデルの処理内容に関する妥当性検証を行う方法
SILS(Software In the Loop Simulation)：モデルから生成されたプログラムコード(ソフトウエア）を使って制御ユニットの動作検証を行う方法
HILS(Hardware In the Loop Simulation)：制御ユニットとして実際のハードウエアを使って制御対象の動作シミュレーションを行い検証する方法

デジタルツインの”なんとか In the Loop”

既知のリスクと未知のリスク

次回の記事もぜひお読みください。

【CSMS第6回】なんとか In the Loop

Masahiko Hisatsugu — Fri, 17 Jul 2020 03:00:00 GMT

アラスジャパンの久次です。

制御システムにはMILS、SILS、HILSといわれるシミュレーション手法が用いられています。

MILS(Model In the Loop Shimulation) : 制御の振る舞いをモデルとして定義し、制御モデルの処理内容に関する妥当性検証を行う方法
SILS(Software In the Loop Simulation)：モデルから生成されたプログラムコード(ソフトウエア）を使って制御ユニットの動作検証を行う方法
HILS(Hardware In the Loop Simulation)：制御ユニットとして実際のハードウエアを使って制御対象の動作シミュレーションを行い検証する方法

デジタルツインの”なんとか In the Loop”

既知のリスクと未知のリスク

次回の記事もぜひお読みください。

【CSMS第6回】なんとか In the Loop

Masahiko Hisatsugu — Fri, 17 Jul 2020 03:00:00 GMT

アラスジャパンの久次です。

制御システムにはMILS、SILS、HILSといわれるシミュレーション手法が用いられています。

MILS(Model In the Loop Shimulation) : 制御の振る舞いをモデルとして定義し、制御モデルの処理内容に関する妥当性検証を行う方法
SILS(Software In the Loop Simulation)：モデルから生成されたプログラムコード(ソフトウエア）を使って制御ユニットの動作検証を行う方法
HILS(Hardware In the Loop Simulation)：制御ユニットとして実際のハードウエアを使って制御対象の動作シミュレーションを行い検証する方法

デジタルツインの”なんとか In the Loop”

既知のリスクと未知のリスク

次回の記事もぜひお読みください。

【CSMS 第5回】サイバーセキュリティにおけるデジタルツイン

Masahiko Hisatsugu — Fri, 10 Jul 2020 03:00:00 GMT

アラスジャパンの久次です。

本日は、ものづくりにおける“サイバーセキュリティ”のブログシリーズ、第5回として、サイバーセキュリティにおけるデジタルツインについてお届けします。

サイバーセキュリティのバリデーションを考える場合、”脅威に対する防衛”に対してだけでなく、”製品の安全保障”に関しても、実際に試作品を作成するのではなく、デジタルツインを活用してテストや検証を進めるのが効率的です。

Gartnerによると、IoT製品に取り組んでいる75%の企業ではすでにデジタルツインの活用を始めているか、1年以内に予定しているとのレポートがあります。しかし実態を見てみると、ほとんどのプロジェクトではパイロットフェーズにとどまり本番活用に至っていないと言われています。

活用されないデジタルツイン

ソフトウエアベンダーは「3Dモデルのフル活用でDXを実現」とか「3Dデータの製品ライフサイクルに亘る有効活用で、エンジニアリング改革を推進」というメッセージを出しており3Dデータ＝デジタルツインのような錯覚を与えています。

皆さんのイメージする”デジタルツイン”とはどのようなものでしょうか？

GEが提案するIIOTのデジタルツイン活用事例では、タービンから送られてくるデータから稼働時間や故障頻度のデータを収集し保全作業の効率化を図ると共に、デジタルツインを使って将来起こるであろう故障を予測し事前にメンテナンスを実施することで運転停止時間を最小化し最適な運用の実現を目指しています。

デジタルツインに含まれる3Dデータはシミュレーションモデルとして活用され、想定される稼働時間や故障頻度を元に応力や振動、熱解析を行い、性能の変化を分析します。3D形状は解析のメッシュを作成するのに利用されますが、製品の将来予測を行う為にはそれ以外の情報も必要です。設計目標として定めた稼働条件や製品仕様としての諸元値、過去のテスト結果や出荷時の実測結果など様々な値（パラメータ）を使いながらシミュレーションの結果を判定する必要があります。

またソフトウエアの変更による電流・電圧の変化が、回路における仕様の範囲に収まっているのかを判断したり、過去の要求仕様を振り返り当時想定されていた利用環境の諸条件を確認するなど、デジタルツインを使ったバリデーションには複数の設計領域をまたがる関連情報が求められてきます。タービンの様に何十年も稼働し続ける製品の場合、当初想定されていた利用条件を逸脱して運用され続けられることも少なくありません。

デジタルツインプロジェクトの多くがパイロットフェーズ止まりになっている原因の一つとして、3Dデータ=デジタルツインと限定して取り組んでいることが上げられています。

ライフサイクルに亘り形を変える部品表

デジタルルツインとは、実際に稼働している製品に関わるデジタル情報のことを言います。
この中には機械的な情報だけでなく、電気/電子的な情報及びソフトウエアに関する情報なども含まれています。

3Dデータは部品表で管理されている一要素でしかありません。部品表には3Dデータだけでなく、要求事項や解析結果、製品スペックなどが関連づき管理されています。
部品表は設計段階の製品構成（部品表）だけでなく、構想段階の製品構成や生産段階の構成、運用時の構成など、製品のライフサイクルに亘っていくつかの異なる形体を持ちます。
前出のタービンの場合、工場出荷時の製品構成だけでなく設置場所に応じたオプションやアダプターの種類、故障により取り換えた部品情報と合わせ、設計当初予測されていた範囲内における故障なのか、想定外の利用による故障なのか等、問題解決に必要な情報を集めるにはライフサイクルを遡って情報を追っかける必要が出てきます。

＜フルライフサイクルデジタルスレッド＞

製品情報を繋ぐデジタルの糸

ソフトウエアアップデートにおけるサイバーセキュリティのバリデーションを行うには、ソフトウエアの変更と連動して変化するデジタルツインが持つパラメータ値を追いかけ、製品安全が保障できるのかを判断したり、セキュリティホールからの攻撃シミュレーションを行い、パラメータが閾値を超えるのかを見てリスクを判断していきます。
この時、製品構成や3Dデータ、諸元値および客先での導入構成や工場出荷時の製品構成、企画と要求事項など、対象となる製品に関わる様々な情報を集める必要がありますが、これらの情報を繋ぐデジタルの仕組みを”デジタルスレッド”と呼んでいます。

【CSMS 第5回】サイバーセキュリティにおけるデジタルツイン

Masahiko Hisatsugu — Fri, 10 Jul 2020 03:00:00 GMT

アラスジャパンの久次です。

活用されないデジタルツイン

皆さんのイメージする”デジタルツイン”とはどのようなものでしょうか？

ライフサイクルに亘り形を変える部品表

＜フルライフサイクルデジタルスレッド＞

製品情報を繋ぐデジタルの糸

Masahiko Hisatsugu さんのアクティビティ

【CSMS第9回】150% BOM

【CSMS第8回】Single Source of Truth

【CSMS第7回】着眼大局

【CSMS第7回】着眼大局

【CSMS第6回】 なんとか In the Loop

【CSMS第6回】 なんとか In the Loop

【CSMS第6回】 なんとか In the Loop

【CSMS第6回】 なんとか In the Loop

【CSMS第6回】 なんとか In the Loop

【CSMS第6回】 なんとか In the Loop

【CSMS第6回】 なんとか In the Loop

【CSMS第6回】 なんとか In the Loop

【CSMS第6回】 なんとか In the Loop

【CSMS 第5回】 サイバーセキュリティにおけるデジタルツイン

【CSMS 第5回】 サイバーセキュリティにおけるデジタルツイン

【CSMS第6回】なんとか In the Loop

【CSMS第6回】なんとか In the Loop

【CSMS第6回】なんとか In the Loop

【CSMS第6回】なんとか In the Loop

【CSMS第6回】なんとか In the Loop

【CSMS第6回】なんとか In the Loop

【CSMS第6回】なんとか In the Loop

【CSMS第6回】なんとか In the Loop

【CSMS第6回】なんとか In the Loop

【CSMS 第5回】サイバーセキュリティにおけるデジタルツイン

【CSMS 第5回】サイバーセキュリティにおけるデジタルツイン