Continuous Engineering導入のご提案

Presentation on theme: "Continuous Engineering導入のご提案"— Presentation transcript:

1 Continuous Engineering導入のご提案
IoT時代を迎えた製品開発の挑戦 【B2-3】 Continuous Engineering導入のご提案 日本アイ・ビー・エム株式会社 GBS　IoTサービス　R&Dソリューション 後藤　禎

2 製品開発の課題 競争力と高信頼性・高品質の確保 開発プロセス変革への打ち手
本日の内容 IoT時代での製品開発 製品開発の課題 競争力と高信頼性・高品質の確保 開発プロセス変革への打ち手

3 IoT時代の製品開発

4 4/28/2019 投影用のみのページです 2. We estimate a potential economic impact—including consumer surplus—of as much as $11.1 trillion per year in 2025 for IoT applications in nine settings. – McKinsey IoT impact – July 2015 1. We estimate that B2B uses can generate nearly 70 percent of potential value enabled by IoT. . – McKinsey IoT impact – July 2015 3. IoT Opportunity - $1.7T by 2020 with 5 year CAGR~16% -- IDC IOT Forecast May 2015

5 IoT時代の製品開発環境の変化 外部要因 内部要因 デジタルをもとに 異業種との協業・ 共同開発が必要 参入が容易 競合相手の 発見が困難
01 0110 0010 001001 IoT Platform 再定義される ビジネスモデル 短期開発と 逐次投入 (アジャイル開発) 電子・電装 ソフトウエア 開発力強化 研究開発 テーマ変化 接続コンポーネントの技術力強化 ビッグデータの 活用力 内部要因

6 投影用のみのページです

7 ビッグデータの活用 ビッグデータの 収集と分析 製品機能へ反映 製品の配布・展開 製品の更新・機能アップOTA 装置の構成管理
01 0110 0010 001001 製品の運用データ メンテナンスデータ 品質保証データ 顧客の評判 外部評価データソース IoT Platform 製品の配布・展開 製品の更新・機能アップOTA 装置の構成管理

8 スマートな製品とIoT時代の製品開発プロセス
スマートな構成要素を持つ製品 01 0110 0010 001001 IoT Platform Engineering Data Analytics System Verification and Validation System Test System Requirements System Design Deployment/ Release to Mfg. Requirements Analytics Implementation Design for Analytics Virtual Verification 製品の運用データ メンテナンスデータ 品質保証データ 顧客の評判 外部評価データソース 製品の配布・展開 製品の更新・機能アップOTA 装置の構成管理 Verification Analytics 製品機能へ反映 ビッグデータの 収集と分析 競争力を強化する 信頼性・安全性 品質を確保する Getting into the basics of CE offering, and connect to next slide as now we can connect the “design time platform” with “operation time”

9 IoT時代のスマートな製品開発に向けて 継続的エンジニアリングの導入
IoT時代のスマートな製品開発に向けて、Continuous Engineering (継続的エンジニアリング）は、創造的破壊をもたらすスマートな製品開発につながるファーストステップとなります STEP3　 創造的破壊をもたらすスマートな製品開発 STEP2 開発と運用をつなぐ仕組み Watson/Analytics活用 STEP1 IoT時代を見据えた製品開発のプラットフォーム 継続的エンジニアリングの導入 Design for Analytics 競争力を強化する 信頼性・安全性 品質を確保する

10 製品開発の課題 競争力と高信頼性・高品質の確保
(自動車業界を中心にご紹介）

11 IoT時代の 製品開発 IoT時代にむけた製品開発の課題 高付加価値化 開発テーマ増大 製品の電装化 部品メーカーの役割の変化
(ソフトウェア化） 部品メーカーの役割の変化 業界を横断した 協業前提の製品開発 変化点 課題 使い方・環境の多様化と組込みフトウェアのコード増大、モジュール化で品質問題が増加 安全性や開発品質に対しての説明責任強化の法令や標準(ISO26262等) の遵守 IoT時代の 製品開発 開発体制が巨大化し、人員不足やそれにともなうスキル低下、品質低下 「システム・サプライヤー」としてシステムで提供する製品の技術力の重要性が増大 クラウドー通信ー制御＋サービス全体をシステムと考える開発（System of Systems)で、システムエンジニアリングの重要性が増大　

12 研究開発費の増加 競争力強化のためのキーワード 直面する問題：競争力強化 競争力強化のための開発テーマ増大 電子制御技術 統合・自動運転技術
環境関連技術 燃料電池技術 ITS技術 ディーゼル技術 ※「自動車産業の課題と展望」 - 経済産業省　より抜粋 ※産経ニュースより抜粋

13 直面する課題：OEM/サプライヤーのビジネスモデルの変化
従来 IoT時代 OEM/サプライヤー協業で システムを開発 OEMは全体構想に集中 システム開発をサプライヤーへ委譲 車両全体機能 の構想 構想設計 構想設計 システム設計 システム設計 システムで 提案できるサプライヤーが有利 部品設計・SW設計 部品設計・SW設計 開発・実装 開発・実装 欧州サプライヤーA：日本でのECU／デバイス受注額2年で2倍

14 例）自動車リコールは届出件数、 1件あたりの対象台数
直面する課題：品質リスク 高度化・複雑化と共に、部品のモジュール化、共通化により、品質上の課題やリスクが増大しています 例）自動車リコールは届出件数、 1件あたりの対象台数 ともに、増加・拡大 ソフトウェアの高度化、複雑化 電気・電子機器の増加、プログラム・コードの増加 複雑なシステムの集合 情報・ノウハウ共有不足 トレーサビリティの難しさ 自動車リコール届出・対象件数の推移 電気・電子機器起因のリコール発生の増加 モジュール化、部品集約の浸透 コスト削減のため、モジュール化が浸透 共通化による影響の増大 ‘69 ‘13 国土交通省【平成25年度　リコール届出件数および対象台数　速報】4/9　抜粋

15 正しいものを正しく作ることが強く要請されている
直面する課題：高安全性・信頼性の要請 法規・規格 顧客 ISO26262 (自動車） 安全・信頼できるものへの期待 IEC62304 (医療機器） RAMS規格 不正に対する 厳しい目 ISO (ロボット） ・・・・ 正しいものを正しく作ることが強く要請されている

16 機能安全に対応する企業文化 マネージメント
直面する課題：ISO26262への対応 「正しく作る」ために 　必要な4つのポイント 安全目標（ASIL) 安全要求 機能安全要求 (what) 技術安全要件 (How) システム設計書 ハードウェア設計書 ソフトウェア設計書 安 全 要 件 / 設 計 生 産 ・ 販 売 廃 棄 ま で の プ ロ セ ス コ ン ト フ ェ | ズ 製 品 開 発 　生 後 分 析 レ サ ビ リ テ ィ 機能安全に対応する企業文化　マネージメント 生産・販売・廃棄 テストケース・結果 マネージメント プロセス トレーサビリティー ASILに基づいた安全設計 機能安全規格で定義されているライフサイクルの適用 安全ライフサイクルを実施する体制と仕組みの管理 要件設計情報に対する整合性・関連性の確保 安全基準に応じたモデルベース開発、テスト手法、レビュー手法など

17 IoT時代の製品開発のために – 継続的エンジニアリング
システム 設計 システム要求 顧客要求 システム・エンジニアリング システム検証・評価 テスト Integration and Validation Decomposition and Definition プロセス・ データ管理 継続的エンジニアリング 製品開発 競争力 強化 高安全性 高信頼性 品質リスク 課題 エンジニアリング 情報共有 “洞察を成果へ！” 継続的検証 “早い段階から成果を検証する” 戦略的再利用 “同様なものを いちから作り直すな!”

18 １．エンジニアリング情報共有 個々の設計者に必要な設計情報や、製品に付随する情報、アナリティクスデータを 利用可能にすることです。正しいデータに基づく、正しい判断を導きます システム 設計 システム要求 顧客要求 システム・エンジニアリング システム検証・評価 テスト Integration and Validation Decomposition and Definition プロセス・ データ管理 製品開発 エンジニアリング 情報共有 “洞察を成果へ！” システム＆ ソフトウエア設計 要求開発と管理 設計コンテキストの 検索と表示 テストと品質管理 タスク・変更管理 RELM Engineering Insight: Developers need to find and use valuable information regardless of its location in the organization. Connecting all of this data across engineering domains, (RQM, CM, QM etc) help developer to make better decisions and is able to reduce the design cycle. OSLC (Open Services for Lifecycle Collaboration) is industry standard to connect all of engineering data and all our IBM ALM product support this protocol. Since OLSC is open standard, not just IBM platform but also third-party vendors to participate and exchange information.

19 ２．継続的検証 製品開発プロセスの初期段階で、物理モデル、システムモデルによるシミュレー ションを実践することです。シミュレーションによる検証を継続的に実施すること で、正確かつ迅速に製品の品質を高め、設計作業の手戻りを減らします システム 設計 システム要求 顧客要求 システム・エンジニアリング システム検証・評価 テスト Integration and Validation Decomposition and Definition プロセス・ データ管理 製品開発 Shift Left 継続的検証 “早い段階から成果を検証する” Virtual Multi-Disciplined Engineering Physical Multi-Disciplined Engineering Continuous Verification Continuous Verification is really about developers to validate the product to meet the the specification from the very beginning, and to verify the design fully incorporates the requirements and performs as designed. This is achieved by using Virtual models, Simulations and virtual prototyping at design stage repeatedly. Virtual Model / Prototype enables early verification and validation before building anything real I think this early and repeated simulation in the cyber space incorporate with idea behind Cyber Physical system. Virtual Verification and validation

20 ３．戦略的再利用 複雑な製品ラインナップの中で、設計者にとってシンプルなコンポーネントを、顧 客が望む機能(フィーチャー)単位で再利用することです Assyや部品だけでなく、要求仕様やテスト項目までを含めた一連の設計情報をコ ンポーネントとして管理し、設計資産を最大限に活用します 戦略的再利用 “同様なものを いちから作り直すな!” Strategic reuse is the practice in terms of any intellectual capital/property is used as much as possible throughout the development lifecycle. The benefit of strategy is very clear when you consider the number of variation in many products We also recognize few best practice such as to define product structure/common components, derive variant reusable component, maintain product versioning IBM and companies like BigLever, pure::variants supports this practice and we believe this is the key driver for mass customization which Industry4.0 address in the engineering domain.

21 IoT時代の製品開発のために – 継続的エンジニアリング
競争力 強化 高安全性 高信頼性 品質リスク 課題 システム 設計 システム要求 顧客要求 システム・エンジニアリング システム検証・評価 テスト Integration and Validation Decomposition and Definition プロセス・ データ管理 継続的エンジニアリング 製品開発 システムエンジニアリング 適用(MbSE) 開発プロセス変革への打ち手 ISO26262, A-SPICE対応 リファクタリング・ アーキテクチャー改革 戦略的再利用 “同様なものを いちから作り直すな!” エンジニアリング 情報共有 “洞察を成果へ！” 継続的検証 “早い段階から成果を検証する” 開発体制改革 部門・組織を跨った協業

22 開発プロセス変革への打ち手 システム・エンジニアリング適用 ISO26262／A-SPICE対応 変更管理・検証の自動化 リファクタリング

23 取り組み事例１ システムエンジニアリングの適用
取り組み事例１　システムエンジニアリングの適用 機能化されたそれぞれのシステムとそれらを統合したシステムとして品質検証が必要 課題 施策 車両/システムレベルの要求から分析を実施する 要求のトレーサビリティーを確保を行う テストツールにつなげ、品質検証を行う

24 システムエンジニアリング適用（MbSE)
要求分析 機能定義 アーキテクチャ 顧客要求とシステム要求の明確化を行う。使われ方をもとに分析する システムが備えるべき機能を明確にする。機能がどの要求を満たすか明らかにする 機能をシステムのアーキテクチャ（構造）にわりあてる。機能を構成要素に担わせ、実現方針の明確化を行う ①手順(手法) ②SysML(言語) ③モデル化 　(TOOL) モデル言語（表記法） OMG SYSTEMS MODELING LANGUAGE Retional DOORS

25 取り組み事例１ システムエンジニアリング適用（MbSE)
モデルを活用して「あいまいさの除去」と「トレーサビリティー」を実現 要求からテストへつなげ、品質向上を図る 9 8 7 6 5 4 3 2 1 車両レベル システムレベル システム設計要求 L0 L1 L2 要求獲得 要求分析 利害関係者の上位要求開発 要求分析・精緻化 機能フロー 状態遷移分析 要求開発 ①：要求開発と管理 構造とｲﾝﾀﾌｪｰｽ ソフトウェア設計 システム設計 実装コード ②：既存資産の有効活用 テスト ④：試作への適用 実装 Simulinkモデル Statefowモデル 仕様値 性能値 ﾄﾚｰｻﾋﾞﾘﾃｨ･ﾏﾄﾘｸｽ ③：ﾄﾚｰｻﾋﾞﾘﾃｨ

26 自動車開発に適用された機能安全の規格の遵守 顧客からの準拠要求（A-SPICE) ソフトウエア比重増加で規格遵守対応が必須と判断 課題
取り組み事例２　ISO26262など規格への準拠 自動車開発に適用された機能安全の規格の遵守 顧客からの準拠要求（A-SPICE) ソフトウエア比重増加で規格遵守対応が必須と判断 課題 施策 文書ベースでのV字プロセスの定義 テスト計画書・仕様書などテスト関連の書式整備 ISO26262のテスト観点をとりいれる

27 取組み事例２ 規格への準拠（Part4対応 ENG9,10）
同時にA-SPICEのプロセスとの準拠性も整えます 顧客 要求仕様書 アイテム統合とテスト システムインテグレーション システム テスト計画書 システム 要件仕様書 システム開発チーム 実装正確性 性能タイミング インターフェース カバレッジ ロバストネス システム開発チーム システムアーキテクチャ設計書 システムインターフェース仕様書 テスト仕様書 電装システム インテグレーション 電装システム要件仕様書 電装システム開発チーム 電装システム テスト計画書 電装システム開発チーム ISO26262の 5つの観点 実装正確性 性能タイミング インターフェース カバレッジ ロバストネス 電装システムアーキテクチャ設計書 電装システムインターフェース仕様書 サプライヤー サプライヤー テスト仕様書

28 現状は、工程毎にチームが存在し、連携は考慮不足、システムはサイロ状になっている
取り組み事例３　変更管理と検証の自動化事例 現状は、工程毎にチームが存在し、連携は考慮不足、システムはサイロ状になっている 顧客からの変更要求が著しく多く、それを正確に製品に適用する必要がある 課題 施策 顧客との変更管理システムの接続 モデル(ソフトウエア）変更に伴う自動検証の仕組みづくり

29 取り組み事例３ 変更管理と検証の自動化事例 顧客変更管理 システム 変更管理 システム HILSテスト３ ビルド３ HILSテスト２
取り組み事例３　変更管理と検証の自動化事例 OEMへ ビルド３ HILSテスト３ OEM社 B社 毎週 ビルド２ HILSテスト２ 顧客変更管理 システム 変更管理 システム 毎晩 ビルド１ HILSテスト１ 変更 チケット 即時 　お客様発表事例　Interconnect 2016　

30 コンポーネント化、共通アーキテクチャ、バリエーション管理により、体系的・戦略的なソフトウェアの再利用をめざす
取り組み事例４　リファクタリング ソフトウェアが複雑化、スパゲティ化して、機能追加の効率が低下し、要求変更に柔軟に対応できない 問題が起きたときに、影響範囲が全体におよぶため、分析や修正に時間がかかる モジュールの開発を委託したいが、インタフェースが複雑で、切り出しできない 多モデルの開発を行っているが、無駄に重複が多く、開発コストが膨大になっている 課題 施策 プロダクトライン開発へのアプローチ コンポーネント化、共通アーキテクチャ、バリエーション管理により、体系的・戦略的なソフトウェアの再利用をめざす

31 コンポーネント指向開発 現状イメージ 目標イメージ 変動性が分散している 機能と部品が対応しない 詳細な関数を組み合わせていく設計
コンポーネントによる設計 機能と部品が対応しない 機能と部品が対応する 低い結合度 高い凝縮度 変動性が分散している 変動が隠蔽されている コンポーネントは弱く結合し、強く凝集している 循環して依存していないこと 【コンポーネント指向開発】 大規模なソフトウェア開発では、要求変更への対応のしやすさや、生産性向上、品質向上のために、システムを再利用可能な部品（コンポーネント）の組合わせとして設計していく。 コンポーネントの凝集度（Cohesion）が高いこと コンポーネントの結合度（Coupling）が疎であること コンポーネントは循環して依存しないこと

32 リバースエンジニアリング（可視化による把握）
コードから構造図を自動作成します 視覚的に構造を俯瞰できるようにモデル上で階層化を行います 分析のベース資料となります

33 取組事例４ リファクタリングの構想化 戦略的な再利用へ
取組事例４　リファクタリングの構想化 「コンポーネント構造評価」活動の成果を参照し、再利用性の高いコンポーネント の構成とするための、アーキテクチャ上のリスクを見直します 派生車種におけるバリエーションを分析し、再利用性を高くするために必要なコン ポーネント構造の基本設計を行います コンポーネント 構造評価 再利用性の高いコンポーネントの構成とする 　戦略的な再利用へ コンポーネント構造の基本設計 再構築 現状構造の 評価と課題 箇所の確認 STEP1 構造リスク分析 STEP3 コンポーネント設計 STEP4 再構築計画 STEP2 製品バリエーション 分析 上流のモデルベース開発整備

34 IBMの提供するソリューション 高付加価値・高品質の製品設計を実現する継続的エンジニアリングへのアプローチとして下記の様な製品設計プロセスを網羅するサービスとツールで実現するソリューションを提供します サービス システムエンジニアリング (MbSE)適用 可視化、モデル化による抜け漏れのない要求分析システム設計(アーキテクチャ設計） 要求→機能→システム設計→機能分担の明確化 プロセス改革支援とツール適用、環境構築 ISO26262/A-SPICE対応 規定される順守事項の適用支援・環境構築 プロセス・成果物定義 構成管理・変更管理 トレーサビリティ ソフトウェア・アーキテクチャー改革 再利用しやすいアーキテクチャー検討 派生開発の仕組み リファクタリング 固定/変動点管理　　　のためツール適用と支援 継続的エンジニアリングを実装する Rational ツール群 要求からリリースまでの可視化とトレーサビリティ(含ISO26262) 分散開発でのプロジェクト管理 設計各種必要情報との連携 等を実現する開発力強化のための一連のツール群の提供 開発体制改革 開発の上流から下流までを含めた総合的な体制の強化のご支援 (組織、スキル、プロジェクト管理、開発環境、ツール適用) Doors DNG Rhapsody/RDM 　RTC RQM RELM ツール

35 システム・エンジニ アリングの導入 (MbSE)
IoT時代のスマートな製品開発に向けて 継続的エンジニアリングを導入し、IoT Platformへの接続、そしてスマートな製品開発へと発展をめざすこが重要と考えられます STEP3　 創造的破壊をもたらすスマートな製品開発 STEP1 IoT時代を見据えた製品開発のプラットフォーム Watson/Analytics技術 顧客要求取り込み変更管理 するプロセス力 STEP2 開発と運用をつなぐ仕組み システム・エンジニ アリングの導入 (MbSE) 統合テストの自動化と検証力の向上 継続的エンジニアリングの導入 競争力を強化する 信頼性・安全性 品質を確保する

36 継続的エンジニアリングの実装 Rational製品群
開発の上流工程から下流工程までをサポートします 要求から設計までのトレーサビリティ、要求とテストのトレーサビリティを管理し、影響範囲の特定や事前シミュレーションによるバグ潰しが可能になります 開発スピード促進や品質向上へとつながります

37

38 ワークショップ、セッション、および資料は、IBMまたはセッション発表者によって準備され、それぞれ独自の見解を反映したものです。それらは情報提供の目的のみで提供されており、いかなる参加者に対しても法律的またはその他の指導や助言を意図したものではなく、またそのような結果を生むものでもありません。本講演資料に含まれている情報については、完全性と正確性を期するよう努力しましたが、「現状のまま」提供され、明示または暗示にかかわらずいかなる保証も伴わないものとします。本講演資料またはその他の資料の使用によって、あるいはその他の関連によって、いかなる損害が生じた場合も、IBMは責任を負わないものとします。 本講演資料に含まれている内容は、IBMまたはそのサプライヤーやライセンス交付者からいかなる保証または表明を引きだすことを意図したものでも、IBMソフトウェアの使用を規定する適用ライセンス契約の条項を変更することを意図したものでもなく、またそのような結果を生むものでもありません。 本講演資料でIBM製品、プログラム、またはサービスに言及していても、IBMが営業活動を行っているすべての国でそれらが使用可能であることを暗示するものではありません。本講演資料で言及している製品リリース日付や製品機能は、市場機会またはその他の要因に基づいてIBM独自の決定権をもっていつでも変更できるものとし、いかなる方法においても将来の製品または機能が使用可能になると確約することを意図したものではありません。本講演資料に含まれている内容は、参加者が開始する活動によって特定の販売、売上高の向上、またはその他の結果が生じると述べる、または暗示することを意図したものでも、またそのような結果を生むものでもありません。 パフォーマンスは、管理された環境において標準的なIBMベンチマークを使用した測定と予測に基づいています。ユーザーが経験する実際のスループットやパフォーマンスは、ユーザーのジョブ・ストリームにおけるマルチプログラミングの量、入出力構成、ストレージ構成、および処理されるワークロードなどの考慮事項を含む、数多くの要因に応じて変化します。したがって、個々のユーザーがここで述べられているものと同様の結果を得られると確約するものではありません。 記述されているすべてのお客様事例は、それらのお客様がどのようにIBM製品を使用したか、またそれらのお客様が達成した結果の実例として示されたものです。実際の環境コストおよびパフォーマンス特性は、お客様ごとに異なる場合があります。 IBM、IBM ロゴ、ibm.com、DOORS、IBM Watson、Jazz、Rational、Rational Team Concert、Rhapsodyは、 世界の多くの国で登録されたInternational Business Machines Corporationの商標です。他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。現時点での IBM の商標リストについては、