DIPROの電子情報管理システム構築サービス

DIPROの電子情報管理システム構築サービスは、21世紀に通用する車載電子制御システム開発を実現するために、ソフトウエアなどの開発成果物や各種データ類の管理要件整備、情報管理のプロセス・仕組み作りをご支援させていただくものです。

現在の車載電子制御システムにおいて、車1台分の組込みソフトウエアは1億ステップを超える時代になっており、電子制御システム開発におけるソフトウエアの比重が非常に大きくなってきています。経済産業省の調査によると、このような開発においては「品質管理」や「仕様/計画の変更の多さ」がトップ課題となっており、度重なる仕様変更や不具合対策織り込みによるバージョンの増加、そして車種違いやグレード違い、仕向地違いが追加となることによるバリアントの増加、これらの掛け算で種類が急増してきていることが原因と推測できます。

このようにソフトウエアの種類が増え続ける中で、開発品質向上や業務効率向上を実現するため、開発成果物や各種データ類の管理要件の整備、情報管理のプロセス・仕組み作りをDIPROがご支援いたします。

DIPROのご支援内容

システムによる開発成果物や各種データ類の管理というと、情報管理だけを目的としたシステムとなりがちですが、情報管理だけのシステムは、設計者などへのユーザーメリットが少ない一方、利用の手間がかかるため、使われなくなる傾向があります。DIPROの強みは、「モノづくりの知識・経験」と「情報技術＝IT」の融合です。ユーザーごとに違うプロセスや開発ドキュメント、データ類の構成を考慮して、ユーザーオリエンテッドを重視した使い勝手の良いソリューションを提案します。

私達は、最初にお客様の業務分析から始めます。お客様特有の業務プロセスや使われているソフトウエアを始めとする開発成果物、データ構成類の運用状況を把握して、改善すべき課題やご要望をリストアップします。お客様が感じている課題やご要望はもちろん、DIPROの有するモノづくり経験やISOなどのモノづくりに関する基準との比較も含め、広範囲の視点で課題をリストアップしていきます。

次に、リストアップした課題の解決方策案を作り上げていきます。あるべき姿を元にシステムで管理すべき項目を明らかにした上で、実際のお客様の業務プロセスに合わせて、システム開発のための業務要件を作成、更に業務プロセスの改善や仕組みなどの課題解決の具体的方策を提案します。ここであるべき姿とは、DIPROの有するモノづくり経験とISO26262（機能安全）やJASPARなどの標準/規準を考慮した、ソフトウエア管理の最適解となります。これらを元に、お客様の実態に合わせた実現項目を提案させていただき、現実的な管理システムの要件定義を作成、システム開発へつなげます。

DIPROでは、モノづくり経験者がユーザーの立場で業務要件やプロセス・仕組みなどを考えるので、ユーザーの手間が増える管理手続きを抑え、利便性を考慮した、モノづくりの品質向上/効率向上のための提案を行います。

ソフトウエア管理システム構築具体例のご紹介

ソフトウエアの管理は、サーバー上でフォルダに分けて「管理」しているケースが多いと思います。しかしフォルダでの管理では、

• 欲しいソフトが見つからない（検索に時間がかかる）
• どのソフトがどの仕様かわからない（再利用できない）
• ソフト変更時の影響分析ができない（抜け漏れ発生）

といった問題が発生してしまいます。DIPROが提案するソフトウエア管理システムの具体例を、以下に紹介します。

例1）ソフトBOMを使ったソフトウェア関連書類の管理による業務効率化

エンジニアリングBOMを導入しているお客様は多いと思います。DIPROはお客様が既に導入しているそのエンジニアリングBOMと連携可能なソフトBOMの導入を提案します。

このソフトBOMでは、最終的にECUへ格納されるバイナリファイルに加えて、例えばそのバイナリの元となっているモデル、および、ソースコード、更にはCONFIGなどのパラメータ情報、ビルド環境などが一括管理可能になります。また、エンジニアリングBOMと連携させることで、商品側の仕様情報との関連付けが可能で、様々な検索効率の向上が図れます。

例2）世代フロー表示によるソフト変更時の影響分析サポート

例1のようにBOMを使うことで、ソフトウェアのバリエーション管理をシステムで行えるようになり、各種情報の関連付けや検索が容易になります。しかし、あるバージョンを変更する必要が生じた場合、その影響範囲を見極める必要があり、それは設計担当者が検討・判断をしなくてはなりません。

そこでDIPROでは、その検討をサポートする世代フロー表示機能を作成しました。具体的には以下のような機能です。

1. ①ソフトバリエーションの世代を視覚的に表現
2. ②あるバージョンを修正した際には、検討すべき範囲を色別して明示

影響範囲の検討方法の一例を説明しましょう。まずSTEP1です。上図に示すようなバリエーションが展開されていて、その中の一つソフトV1.1を修正する必要が生じたとします。その際、修正したソフトV1.1.1をリリースするだけでは不十分で、「V1.1のベースソフトであるV1.0にも修正を当てなくてよいか？」、「V1.1から派生したV1.2にも同じ対応をする必要はないか？」など、その影響範囲を設計者は見極める必要があります。

今回DIPROが提案する「電子情報管理システム構築サービス」では、前述のようなV1.1の親子関係を視覚的に表現し、更に色を区別することで、その設計担当者の検討範囲の理解を容易にしています。

次にSTEP2です。検討の結果「V1.0は修正不要。しかし、V1.2は修正が必要」となったとします。設計担当者がこの判断を「電子情報管理システム構築サービス」に入力すると、本システムは、次にV1.2の子供であるV1.5を色別し、担当者に検討を促します。

このような手順によって、あるバージョンを変更した際に必要な影響範囲の検討漏れ防止をサポートしています。

最後に

ここで紹介したのは私たちが実施している「電子情報管理システム構築サービス」の一部です。これを担当しているDIPRO エレクトロニクスエンジニアリングサービス部は、自動車OEMの出身者が多く、自動車業界関連のOEMやサプライヤのサポートの経験も豊富です。これらの自動車関連のシステム開発の経験を活かして、業界特有の開発プロセスへ対応した業務改善やシステム提案、お客様の使い方に合わせたカスタマイズを含めた電子情報管理システム構築サービスをご提供します。開発品質向上や、業務効率向上でお悩みの際には、ぜひ一度ご相談ください