事例にみるシステムズエンジニアリングの特徴 - ipa（skyactiv） •...

Software Reliability Enhancement Center© 2016 IPA,

事例にみるシステムズエンジニアリングの特徴

2016年10月20日独立行政法人情報処理推進機構（IPA)

技術本部ソフトウェア高信頼化センター（SEC)

資料２ (16-SEWG-3）

2Software Reliability Enhancement Center© 2016 IPA

本日の論点

製品・サービスの新たな開発手法が求められている背景【例】システムが複雑：人工衛星、自動車自分のレベルで仕様を決めることができなくなった：SoS/IoT サービスとして既存の製品を転換させるニーズ：途上国への製品展開（保育器）ステークホルダーが多く要求も多様：SoS/IoT

これらの開発手法として有効な手段はなにか（それはシステムズエンジニアリングでいうところの何なのか）


新たな開発手法が求められている背景と事例

SKYACTIV 保育器オーレスン橋 SoS（IoT）

1.複雑なシステム（構造、対象） ○

2.自己完結できない（複数製品の連携） ○

3.やってみないとわからない（物理的難しさ）

○

4.製品環境変化 ○

5.多岐に渡るステークホルダーによる多様な要求

○


1. 複雑なシステム自動車での例

出典：SWEST16※「SKYACTIVエンジン開発」人見氏講演資料※16th Summer Workshop on Embedded System Technologies

内燃機関の熱効率を改善するための制御因子非常に多くの制御因子を効果的・適切に制御する必要

あらゆる機能に拡大

複雑なシステムを限られたリソースで迅速に開発し続けるには，開発そのものを机上で効率良く行う

出典：マツダ「SKYACTIV-G制御システムとモデルベース開発」2015


1. 複雑なシステムシステムの複雑化への対応

システムが複雑化することによる問題点要素と要素が絡み合い複雑となり見通しが悪くなる。全体設計、個別設計の不

備が発生しやすい設計時の不具合が見つけにくい、テスト・検証での不具合発見では影響範囲が

大きく手戻りが大きくなる

解決法全体としてどうあるべきかを考え、個別要素に分解していく：俯瞰的・系統的

アプローチ複雑なものをなるべく簡単に表現し共有できるようにする：抽象化・モデル化

(次頁参照) テスト・検証の上流シフト


反復的なアプローチ

全体俯瞰を可能にし、システムを俯瞰的に細部までデザイン、実現していくには、抽象度をしっかりと制御しながら、右図のように各プロセスを反復する中で、段階的に詳細化を進める事が有効である。

抽象度高

抽象度低

システムに対する要求

システムのふるまい

システムのアーキテクチャ（機能と物理）

システムのVerificationと

Validation

1. 複雑なシステム【参考】新しいシステムズエンジニアリングアプローチ

出典: A primer for Model-Based Systems Engineering

複雑なもの、新しいものは、右のアプローチを!増加するComplexityをマネジするのは抽象度のコントロールが重要!


1. 複雑なシステムマツダ(株)様事例: SKYACTIV-G制御システムとモデルベース開発 (2015)



出典：INCOSE Systems Engineering Handbook

2. 自己完結できない（複数製品の連携例）

IoTやSystem of Systemsのように機器が連携することにより新しいサービスが創出される。個別機器の考慮だけでは想定できない様々な問題が発生する可能性大。

カメラプリンタ

新しいサービス

従来の考慮範囲

新たな考慮範囲

機器への要求

機器への要求

解決法従来までの個別製品の考慮範囲からIoTでの環境、条件までを

考慮範囲に拡大。俯瞰のレベルを１段上げる。境界線の条件を明確にし、インターフェイスを共通化する。

(モデル、フレームワーク、アーキテクチャ)次頁参照


出典：インダストリー4.0 実現戦略報告書出典：Smart Grid Reference Architecture

Smart Grid Reference Architecture RAMI4.0

• 範囲を限定することによって、ArchitectureのReference Modelをつくることができる

• 品質、安全性、相互接続性をこのモデル上に位置づけながら担保するための方針

• Architecture Reference Modelは、「時間軸x空間軸x意味軸」で構成

2. 自己完結できない（複数製品の連携例）【参考】機器連携への考え方


3. やってみないとわからない（物理的難しさの例）

内燃機関の制御等要求が高度になるにつれ従来までの実機での動作確認を繰り返す開発手法では、コストや開発期間が膨大になってしまう。（最適値に辿り着けない可能性も考えられる）制御パラメータも膨大になることから人間の限界を越えてしまう。（SKYACTIV）

• 現状のエネルギー効率は3割、7割は損失• 圧縮比を高めれば効率は良くなるが、異常燃焼が発生

出典：SWEST16※「SKYACTIVエンジン開発」人見氏講演資料※16th Summer Workshop on Embedded System Technologies


3. やってみないとわからない（物理的難しさの例）開発の質と速度を上げる手法例

モデルベース開発＝プロセス+モデル＋シミュレーションによるQCDの向上

シミュレーション



4. 製品環境変化（途上国への製品展開：保育器）

環境の違い電力インフラ、自然環境等の違い→発展途上国へ支援された医療機器は5

年以内に95%が故障（例：2004年のスマトラ沖地震後インドネシアに支援された8台の保育器は2008年にはすべてが故障）

自前での保守能力の欠如（部品供給、専門技術者不足）途上国での乳児死亡数年間400万人。内180万人が生後3～7日温めるだ

けで生存できることが判明→簡易な保育器で多数を救える

同じ「保育器」でも求められているものが違う

解決の例途上国でも一定の供給体制がある自動車部品の利用。高度な医療技術者

による修理も必要なく自動車修理工で対応できる。（自動車のヘッドライトで温める）


5. 多岐に渡るステークホルダーによる多様な要求オーレスン橋

多岐に渡るステークホルダー２国間の政府、国民、道路、鉄道事業者。

多様な要求①多様な専門領域: 各種構築技術 (橋梁、人工島、トンネル、道路、鉄道)、船舶通過関連、交通予想、海洋環境関連、運営・メンテナンス関連等②２国法規: 両国間をつなぐため、両国の規制や基準を考慮する必要性③鉄道方式の違い: 右側左側通行の違い、電力供給方式の違い④環境問題

解決法計画時に7年もの期間をかけて徹底的に要求分析を実施


製品・サービスの新たな開発手法の整理案【これまで】【IoT時代】

個別パーツを組み合わせて、全体の設計、開発（個別要素ごとのエンジニアリング手法）

開発アプローチ方法

製品・サービスの形態個別の製品、サービス

俯瞰的・系統的なアプローチ（システムズエンジニアリング）

複数の製品、サービスの連携

開発方法のパラダイム転換

• ①→⑩の順次開発• 手戻りコストが発生• 全体最適が図りにく

い

パラダイム転換 ⇒ 考え方・観点を変える、各プロセスが変わる課題考え方・観点の変化が求められている ⇒ 既存のプロセスから変えられない(やらない)

プロセスに落とし込めない(できない)解決の糸口・既存のプロセスから抜け出せない障壁ドメイン固有の事情の明確化 ⇒ 一般化できないか?・プロセスに落とすためのツールボックス

テスト、検証段階をあらかじめ考慮した上流、設計へ転換・全プロセスの発想転換・開発順序の柔軟化・全体を俯瞰し手戻りを低減

上流、設計が工夫され効率化されたテスト、検証段階

�事例にみるシステムズエンジニアリングの特徴本日の論点新たな開発手法が求められている背景と事例1. 複雑なシステム� 自動車での例1. 複雑なシステム� システムの複雑化への対応スライド番号 61. 複雑なシステム�マツダ(株)様事例: SKYACTIV-G制御システムとモデルベース開発 (2015)2. 自己完結できない（複数製品の連携例）スライド番号 93. やってみないとわからない（物理的難しさの例）3. やってみないとわからない（物理的難しさの例）� 開発の質と速度を上げる手法例4. 製品環境変化（途上国への製品展開：保育器）5. 多岐に渡るステークホルダーによる多様な要求� オーレスン橋製品・サービスの新たな開発手法の整理案

事例にみるシステムズエンジニアリングの特徴 - ipa（skyactiv） •...

Documents