volvoバナー

Volvo社でのGraph データベースの自動車開発への適用例を動画で見ることが出来ます。動画は、Neo4j社によりYou tubeで公開されており、どなたでもご覧いただけます。この動画は、VolvoのShared service部門のteam leader のFabien Batejatさんが説明されています。概要は、現代の自動車開発の複雑さを説明し、それに対してGraphがどのように役立つかを、Volvo社が実際に作成したアプリケーションのデモを使用して説明しています。自動車開発に関わるお客様にとって、有益な情報だと思いますので、ぜひ動画をご覧ください。

また、本ページでは、日本語訳を作成しましたので、動画と合わせてご覧ください。

動画和訳

VolvoShared serviceのteam leader です。

私達は、グラフ技術の専門家です。

また、VolvoGraph intelligence platformのオーナーです。

本日は、Graphを車づくりにどのように活用しているかを説明します。

現在の車づくりのチャレンジから開始します。

現代の車づくりはとても複雑です。

Volvo車は、複雑な製品です。100の通信ブッシュを持ちます。車全体に情報を伝達します。

200Contorol UnitVolvo車に付いています。

これらのControl Unitにより400の機能を実現します。

例えば、ブレーキ、加速、歩行者との衝突緩和、マッサージ、オーディオ、GPS…などです。

400の機能は2,000のソフトウェアコンポーネントにより実現されています。

車両全体からくる10,000のシグナルをソフトウェアが処理しています。

車は、30,000のハードウェア部品から作られています。

ネジから、フロントガラスまで。

これらの全ての可能な組み合わせとして、車1台につき、100万通りはありますが、

あなたが、Volvowebサイトで選んでデザインしたお気に入りの車で正しく動かなければいけません。

また、あなたがVolvoを運転しているときにクリティカルなバグや安全面の問題があってはなりません。

これらの情報をどのように把握するか?

ここにいる方々は、このような事をされていると思います。

Excelに表を作ったり、Visioで図を作ったり、Rapsodyでモデルを作ったり、PowerPointでレポートを造ったり、リレーショナルデータベースにしまったり。

TeamcenterSystemWaverのようなVirtual Managementが出来る特殊なツールを使ったり。

問題は、これらの様々な種類の大量なデータは、1つの車両を表現しているのに、100の別々の貯蔵庫にしまわれている事です。

ナビゲートするのがとても難しく、お互いがどのように関係しているかBig pictureを理解するのが難しいです。

ソリューションとして、「複雑な製品開発をシンプルにする」ということはよく聞きますが、簡単には実現できません。

なぜなら、現代の車づくりは、これらに直面しているからです。

Autonomy(自律)、Electrification(電化)Connectivity(接続性)Sharing(共有)Multiple brand & segmentsSystem Of Systems。

Autonomy

自動運転を作らなければいけません。

つまり、ユーザにとってよりシンプルな車を作る必要があります。

しかし、作り手にとっては、より作るのが複雑になります。

Electrification

2019年以降に発売するVolvo車は、あるレベルの電化規制に従わなければいけません。

Connectivity

Volvoはすでに、デバイスと接続できます。

また、今後もいつもデバイスとの接続性を良くしていきます。

今日でもスマートフォンでドアのロックを操作できます。

車を見つけられます。ガソリンの残量を確認できます。

将来的には、もっと色々なことが出来るようになります。

機能をダウンロードできるようになります。

Sharing

Volvoは新たなシェアリングソリューションを開発しています。

近い将来、あなたが車を所有することを望まないのであれば、所有する必要はないです。

あなたは、所有することなく車が必要な時にだけ使えます。

Multiple brand & segments

複数のブランド

複数のセグメント

Gerlyグループで、volvo単独ではなく、プラットフォームやソリューションを共有する機会があります。

例えば、LINK&COや、Polestarと共有する必要があります。

System of Systems

車がスマートシティの一部となります。

周りの環境とコミュニケーションします。

つまり、他のVolvo車や、他社の車、インフラなどです。

Cloud Source Data

クラウドのデータをシェアすることで、車のドライバーが過去よりも良い判断が出来るようになります。

Machine Learning

例えば、メンテナンス時期を予測することができます。

ドライバーや乗車している人の利便性をあげることもできます。

Third party access

In car deliveryや、in car pick up、デジタルコンシェルジェサービス、深夜の燃料補給サービスなどがあります。

Personalization

Volvoは、個人ごとの設定やアプリケーションが可能です。

Volvoに乗った時や、借りている時にあなたは、いつでも、自分の車だと感じます。

Product Evolution

あなたの車は毎日良くなります。

新たな機能がアップデートされます

Time to market

タイムトゥマーケットを削減したいです。

より早いペースで製品を顧客にデリバリーしたいです。

Unknown

その他、不確定な事

つまり、私達の製品の複雑性を下げれると主張することは、まぼろしです。

現在、車は、マーケットで最も複雑な製品のひとつでしょう。

しかし、この製品の複雑性を理解する事は、とても興味深いです。

なぜならば、アクシデントを起こす可能性がある複雑性の一部を知りたいからです。

そのような部分は、なくすべきです。

なぜなら、私達は、間違ったツールや方法を使っているのかもしれません。

私達は複雑性の一部を理解したいし、複雑性の必要な部分も理解したいです。

そうすることで、私達は製品をマネージできます。

必要不可欠な複雑性を、絶対に最小限の複雑性にすれば、我々は製品を我々の品質、安全、利便性と供に想定した範囲でマーケットに出せます。

それは、様々なデータを扱い、データはそれぞれの貯蔵庫に保存されている現状、どう実現するべきでしょうか?

我々はビッグピクチャーを理解する必要があります。

データをナビゲートし、システムの複雑性を理解し、意味を理解すべきです。

グラフがどのように、それを助けてくれるか見ていきます。

グラフにVolvo車をサポートしてもらうために、私達はグラフで何が出来るでしょうか?

我々は、グラフを私たちの多くのデータシステムとのインターフェースに使えます。

ドキュメントリポジトリに隠れている依存度を明らかにしてくれます。

これは一つの例です。

そして、今までは隠れていたナレッジを探索します。

ナレッジを異なる視点から探索します。

ビッグピクチャーを見ることもできるし、深く詳細を調べることもできます。

つまり、異なるサブシステムレベルとか、より深く詳細を知ることができます。

私達は、それをモデリングプラットフォームとして、データビジュアライゼーションツールとともに使うこともできます。

私達は、望んだ時に、データを直接モデリング出来ます。

グラフだからできる解析を行うことが出来ます。

例えば、DSMDesign Structure Matrics)解析です。

それは、システムデザインのループを発見し、なぜデモでうまくいかなかったかが分かります。

クラスターやシーケンスは、良いプロジェクトプランニングをサポートしてくれます。

これらにより、私達はシステムデザインの品質や改善点を理解できます。

また、機械学習やNLPなどのAIソリューションにもグラフを適用できます。

ナレッジグラフを拡張します。

例えば、新たなリレーションを予測したり、多くのセマンティックを追加して多くの意味をグラフに与えたりできます。

また、予測ポテンシャルをあげるために機械学習エンジンにグラフのデータを与えることもできます。

AIGraphは、良い2方向の関係があります。

これらは、私達の開発プロセスをサポートしてくれるとても興味深いアプリケーションです。

では、私達は、Volvo車とグラフで実際になにをしているか?

我々は、これらをすべて実施しています。

私のチームは、Neo4jデータベースの上にアプリケーションを開発し、1度に1つのユースケースですが、Volvoの既存のデータシステムと接続しています。

左の列がその例です。

また、人間のユーザのためにGUIを開発し、データを理解して、操作して、解析して、などなどが出来るようにしています。

ポテンシャルや、このナレッジグラフで私たちが将来出来るようになること、今は、まだ、把握しきれていません。

私達は、ポテンシャルを発見している所です。

これを良くするために、私達はAIレイヤーを持っています。

フロントエンドに持ち、データをナレッジグラフに登録しています。

システムズエンジニアリングのために、私達がグラフで何をやっているかを説明します。

このデモでは、アプリケーションで実現される数あるユースケースの打ちの、1つのユースケースに着目します。

これは、functional disposition(機能説明)とよばれています。

Volvo車でのfunctional dispositionの目標は、顧客のニーズに基づいて、全ての製品機能の機能マップを作ることです。

我々は、製品を顧客視点で見る事から開始します。

また、全ての使用方法のコンテキストも見ます。

そこから開始して、私達は製品機能をボトムレイヤーにマップします。

機能があわさって、異なる使い方のなかで、顧客のニーズを満たすかを記述します。

例えば、この例です。顧客のニーズは、快適な気候です。

そして、快適な気候が、車の中で異なるコンテキストで実現されます。

車のシートに座ってるときとか、仕事に行く前に朝食を取っているときとか。

これは、とてもシンプルな例です。

機能として、温度管理機能、他は、エアフロー管理機能があります。

それらが、両方で快適な気候を作り出します。

これは、大きなグラフではありません。

このグラフには、数万のリレーションが登録されています。

しかし、注目すべきは、このグラフの中のリレーションデータは、volvoの既存のどのデータベースにもないです。

既存のデータベースが持っているものは、機能のリストです。

つまり、このグラフの中のリレーションデータは、多くのVolvoの社員の頭の中にあったものです。

各社員の頭の中の知識を統合して、この知識が作られるわけです。

私達は、VolvoFunctionオーナー達の知識をグラフにマップしました。

その作業は、数年かかりました。

私達は2015年に開始して、現在(201912月)も完成していません。

80-85%のユースケースをカバーしただけです。

しかし、これは、あるVolvo車の重要なナレッジソースとなっています。

なぜなら、私達は多くの機能を作成して、それが車全体として、どのようにつながっているかが分かるからです。

我々が何が出来るかデモで見ていきましょう。

まずは、ファンクションオーナーの視点です。

ファンクションオーナーは、機能の仕様を決定し、開発する人です。

そして、私達は、functional dispositionがシステムデザインアナリストの視点でどう見えるかを説明します。

そして、プロジェクトリーダーの視点でどう見えるかを説明します。

まず、Function Ownerの視点で説明します。

これは、アプリケーションのGUIです。

裏側で、Neo4jGraphデータベースとつながっています。

私は、この機能「Global Opening & Closing」を見たいです。

Global Opening & Closingとは、車をロックしなければいけない時に、窓を開けっぱなしにしていたり、

サンルーフを開けたままにした場合、キーのボタンを長押しすると、それらを閉じてくれるものです。

このようにできます。

これは、シンプルな例です。

このGlobal Opening & Closing機能を4つの機能が関わっています。

真ん中のノードは、同じ名前(Global Opening & Closing)です。

我々は、それぞれが、どのように関係しているか見る事が出来ます。

Global Opening & Closing機能には、ロック、アンロック機能が必要です。

また、サンルーフ操作機能や、窓操作機能は、いつ開いて、いつ閉じるかの情報が必要です。

我々がその情報を持っていると、1つの機能の何かを変える事は、これらの他の機能に影響を与えるかもしれないと分かります。

すると、私は、この他の機能の担当者と一緒に作業する必要があります。

私が何かを変更しても、全体として、正しく統合されてなければいけません。

この情報が人々の頭の中にしかなければ、プロジェクトミーティングやワークショップなどに適切な人を呼ぶときに入念な確認がいります。

これが、私が先ほど見せたデータです。

4つのproduct functionが、Global Opening & Closing機能と関係しています。

これが、私が、誰と仕事をするべきかのリストです。

これは、この機能を担当する人のリストです。

私は、ワークショップに誰を呼べば良いか明確にわかります。

他の例として、私は、他のcustomer functionと私のproduct function

どのように関係しているかを知りたいです。

なぜなら、私の機能は、より多くのcustomer functionと関わっているかもしれません。

私がbasic central lockingという機能のproduct functionオーナーだったとします。

それをNeo4jで調べれば、Global Opening & Closingと、Welcome lightsCustomer Functionと関わっていることが分かります。

Welcome lightsとは、誰かが車をアンロックした時に、ライトが何かする機能です。

他の例として、私の機能は、私が今考える他の機能、例えば、Hazard warningと関係があるか知りたいです。

Hazard warningとは、高速道路で前に障害物があるなど、強くブレーキをした時にウインカーが点滅して、後方車両に警告をだすものです。

basic central lockingは、ロック・アンロックの時に点滅させるためにHazard warning illuminationが必要です。

これは、おそらく、あなたが、車をロックする時に車が少し点滅すると思うので、気づいていると思います。

こういうことが、functional dispositionで出来ます。

あなたはVolvoを理解し、ナビゲート出来ます。

あなたは、自分のproduct functionが他product functionとどのように関係しているか、正しく理解できます。

あなたが、仕様を変えた時に誰と話をしなければいけないか、なぜなら、自分の仕事が他人の仕事に影響を与えるかもしれないからです。

違うユースケースを見てみましょう。

システムデザインアナリストの視点では、DSMDesign Structure Matrix)解析が出来ます。

基本的には、グラフの隣接行列です。

あなたたちは、グラフに関係する人々なので、どういうことかわかると思います。

基本的には、この図のように、異なるコンポーネントに関するリレーションを行列の表形式で表現したものです。

DSM解析により、システムエンジニアは、システムデザインの品質を知ることが出来ます。

そして、プロジェクトリーダーは、その情報をもとに、プロジェクトを計画出来ます。

DSMを使用すると、feedbackがあるかを知ることが出来ます。

DSM解析は、2次元の行列表を使用します。

今日、私達が買える大半のツールは、2次元の行列表を使用します。

全てのリレーションがマップされます。

左のマトリックスを見ると、コンポーネント3は、コンポーネント2と7と依存関係があることが分かります。

DSM解析は、行列の対角化が見つかるまで行列を許可します。

対角線の下に要素がある場合は、それらのコンポーネントがループに関与していることを意味し、そのループは適切ではありません。

なぜ、良くないか?

あなたが、機能1の担当をしているとイメージしてください。

そして、機能2が機能1に依存しています。

あなたが、機能1の変更をすると、それは機能2に影響を与えます。

つまり、機能2のオーナーは、おそらく、再度、作業しなければいけません。

また、機能1が直接か間接的に機能2に依存していると、あなたは、ループに入ってしまいます。

つまり、あなたが機能1を変更する事により、機能1の他の部分が影響を受けます。それは、たいていネガティブなものです。

なので、私達は、このループを避けたいです。

DSM解析はこのようなループを発見するのに役立ちます。

DSM解析はシステムのクラスターを発見するのにも役立ちます。

DSMアナリティクスは、マトリックスの対角領域をブロックにすることにより、システム内のクラスターを見つけるのに役立ちます。

それぞれのブロックがクラスターです。

ブロックがオーバーラップを持っていなければ、これらのクラスターは互いに独立しています。それは、プロジェクトオーナーにとって、とても興味深いものです。

なぜなら、プロジェクトチームをうまく計画できるからです。

これらの人々は、独立して仕事が出来るとわかるからです。

また、我々はシーケンスも取得する事が出来ます。

つまり、開発期間を最適化するための仕様決めや開発の順番です。

それは、とても魅力的な機能です。

これらを調べたところ、DSM分析のすべてのアルゴリズムがグラフ理論に基づいていることがすぐにわかりました。

functional dispositionは、グラフにマップされています。

ならば、DSM解析もグラフに直接適用すべきです。

マトリックスは一度、忘れてください。

ループは、グラフの中でもループです。

クラスターもクラスターです。とてもシンプルに見えます。

しかし、ときどき、マトリックスで見たくなるものです。

なので、私達はアプリケーションを作りました。

それは、グラフ平面でのDSM解析です。

これは、functional dispositionです。

これをマトリックスにしてみましょう。

私達は、Cypherを直接使用したので、このクエリーは最適化されていません。

Neo4jtraversal APIを使用すれば、おそらくこの結果を1秒で取得できるでしょう。

しかし、10秒程度の待ち時間でも、私達にとっては十分です、なぜなら、このマトリックスを頻繁に出すことはないからです。

ここでは、コンポーネントを表示しきれていません。

この図の下にも、多くのコンポーネントが存在します。

これは、とても興味深い情報です。

これで、システムエンジニアとFunctionオーナーは、一緒に働くことができ、システムを少しずつ、作り直すトライができます。

ループの無い製品デザインを作るトライが出来ます。

そして、私はソリューションをシステムにロードします。

このシステムは、前のシステムよりもはるかに良い事が分かります。

もちろん、いくつかのミスは含んでいると思いますが、仮想的に、システムのループの数が約1000減りました。

私達は、品質を改善しました。

DSM解析を、自然なクラスターがシステムにあるか調べることが出来ます。

2、3のクラスターがあります。

それらは、完全に分離されていません。

それらは、インターフェースを持っています。

グラフで見ると、これが、2つの近接した分離されていないクラスターのインターフェースです。

より良い方法があるかもしれません、自然のクラスターをさがすのではなく、クラスターをシステムデザインに強いることができます。

なぜ、それをやらないのか?

私達が新しい車を作る時、テストをします。

開発初期は、テストトラックでテストします。それで充分です。

テストトラックでテストすることにより、様々なことがあきらかになります。

加速、ブレーキ、ターン、エンジン停止、それでスピードの情報としては、十分です。

機能のサブセットで十分です。

そして、私達は新しい車を公道でテストします。

そこでは、法規による要件があるため、より多くの機能を実装する必要があります。

そして、私達は第3のクラスターの機能を追加します。

例えば、動力性能の改善など。

もしくは、その他の快適にする機能など。

それが、エンジニアがNeo4jでやっていることです。

見てみましょう。

黄色のノードがクラスターノードです。

機能のノードがクラスターノードとリレーションを持っています。

basic central lockingと、Vehicle locking/Unlockingは、2つのクラスターに属しています。

これらの機能を分離させたいです。

いくつかの機能は、最初のクラスターに、そのたの機能は後ろのクラスターに分けられます。

このアプリケーションは、分離する機能をもっていますので、実行してみます。

分離が出来たので、結果を見てみます。

未だ、二つのクラスターを持っていますが、Vehicle locking/Unlockingbasic central lockingは、二つに分離されています。

そして、splitのリレーションが付いています。

splitのリレーションは、もともとは、1つのノードだったことを表しています。

これは、インターフェースです。

このインターフェースは、どこかで解決しなければいけません。

しかし、今ではありません。

今は、車を納入することに注力しているので、テストトラックで車をテストします。

私達のアプリケーションに戻ります。

クラスター化します。分離した結果をみてください。

Graphで直接見てください。

これら、非常に良くクラスタ分けされています。

そして、マトリックスでも、明らかに分かれている事が分かります。

対角線上のブロックです。

プロジェクトプランニングのためにGraphをどう使えるか

私は、既に少し話しました。

マトリックスを三角化して、全てのループを無くすことにより、

私達は最適なシーケンスを得ることが出来ます。

私達は、業務を最適化するために、これらの機能にとりくむことが出来ます。

シーケンスのクラスターと供に、プロジェクトリーダーはJIRAでプロジェクトをプラン出来ます。

JIRAとは、私達が使用しているプロジェクトプランニングツールです。

私達は、クラスター機能に着目して、この機能を初めにやる、あの機能を2番目にやる、機能の依存度によりこれらの機能は一緒にやる、

などと計画できます。

このようにプロジェクトプランニングに役立ちます。

このアプリケーションは、作成中です。

基本的に、これらの機能が互いに関係しているか、いつ私たちはそれらの機能を開発するべきか?、

どのプログラムインクリメント(つまり、 Volvoでは12週間)で実施するか、どのチームが実施するべきかを示しています。

つまり、ループは殆ど閉じています。

Your Name (required)

Your Email id (required)

Your organization (required)

Phone No (Please mention country code also)

Comment

Your Name (required)

Your Email id (required)

Your organization (required)

Phone No (Please mention country code also)

Comment