ーー自動車のシステムは最近、自動運転など急に聞かれるようになり、大きく変わりつつあるということもあり、その中でmrubyが活用される余地が色々あるということで、そういった様々な自動車のシステムの変化を中心に、その他mrubyへの取り組みについてもお話をお聞きすることができました。
以下は講演の内容です。

---

TOPPERSプロジェクトについて

---

TOPPERSプロジェクトでのmrubyへの取り組み

---

名古屋大学 組込みシステム研究センター(NCES)

https://www.nces.i.nagoya-u.ac.jp/

名古屋大学で「組込みシステム研究センター」を設立し、今年で12年目になりますが、大企業と連携した共同研究を行なっています。
これは、基礎研究をやるというよりは、大学の持っている基礎的な技術シーズをもとに実用化すること、また人材育成を目的にしています。

設立目的

組込みシステム分野の技術と人材に対する産業界からの要求に応えるために、組込みシステム技術に関する研究・教育の拠点を名古屋大学に形成

活動領域（スコープ）

• 大学の技術シーズを実現／実用化することを指向した研究
• プロトタイプとなるソフトウェアの開発
• 組込みシステム技術者の教育／人材育成

研究プロジェクト例

• 車載制御システム向けSPF（AP／A2Pコンソーシアム）
• ダイナミックマップ（DM2.0コンソーシアム）
• 宇宙機向けソフトウェアプラットフォーム（スペースワイヤOS）
• 車載組込みシステムセキュリティ強化技術

---

---

APTJ株式会社

http://www.aptj.co.jp/

2年前に、名古屋大学発のベンチャ企業である APTJ株式会社 を立ち上げました。
車載制御システムの分野でソフトウェアプラットフォーム（広い意味でOS）の「AUTOSAR」の標準がかなり広く、ほぼ国際標準として使用されつつあり、最近急激にその流れができてきており、状況が変わりつつあります。
「AUTOSAR」はドイツ発の標準であり、日本発の実装がなかったので、実装の部分だけでも日本発で作れないかということで、今までやってきた技術をベースに、日本発の実装を作り販売しようということで会社を起こすに至りました。

APTJの必要性

• AUTOSARが車載制御システム向けのSPF（広い意味でのOS）の国際標準になる流れの中で、車載制御システム向けのSPFが海外製だけになる恐れがある。日本初の組込みOSを作りたい。
• 名古屋大学における研究開発だけでは不十分と判断。

APTJの活動と位置づけ

• 名古屋大学における産学連携の研究開発成果を活用して、車載制御システム向けのSPFを開発・販売

  【技術的な強み】

  RTOS、機能安全、サイバーセキュリティー、マルチコアプロセッサに関する要素技術と知験

• 自動車メーカー／自動車部品メーカーと共同でSPFを開発
• パートナーソフトウェア企業との協力 コンソーシアム型のベンチャー企業
• 名古屋大学発ベンチャー企業として設立

車載（組み込み）制御システム開発の現状と課題

---

現状（自動運転登場前）と課題

自動運転システムが登場する前には、自動車内で非常に多くのコンピュータが使われていて、普通車だと80個、高級車では100個位の車載コンピュータのユニット(ECU)が色々な目的で使われていましたが、ハードウェア・ソフトウェアともに複雑化していて、最近では、一台の自動車に入っているソフトウェアの数は一億個ほどあるのではないかと雑誌などで言われています。

このようにソフトウェアが複雑化してくると、信頼性、安全性が非常に重要で、特に自動車の場合、 人命に関わってくることもあり、安全性がとにかく重要になってきます。

しかし、信頼性や安全性を追求すると非常にコストがかかり、 自動車分野は特に品質要求が非常に厳しく、当初考えていたコストの３倍になることもあったり、おそらく他の分野のソフトウェア開発に比べると１桁ぐらい違うのではないでしょうか。

設計生産性の向上、開発の効率化が求められ、さらに、ECU（コンピュータ）の数の増加、ネットワーク構成の複雑化への対応も迫られているようです。
また、組み込みシステム技術者（人財）不足の問題もコンスタントにあり、人材集めは深刻化しているようです。

---

課題に対するアプローチ

これらの課題を解決するためのアプローチとして以下のようなものが考えられます。

ディペンダビリティの確保・向上

• 機能安全規格（ISO 262622、もうすぐ第２版）の規格に盛り込まれた知見を取り込んでいくことや、 セキュリティガイドライン（ SAE J3061）への対応
• トップダウンな設計コンセプト（安全コンセプト、セキュリティコンセプト）

設計生産性の向上（開発の効率化）

• ソフトウェア開発プロセスの地道な改善
• 設計の抽象度を向上させるためのモデルベース開発
• 設計資産の“良い”再利用を可能にするためのプロダクトライン開発とコンポーネント開発
• アプリケーション開発底上げのためのプラットフォームと、その共通化・標準化（プラットフォームベース開発）※高田教授の専門分野
• 仮想環境（シミュレータ）による検証の効率化

ECUの数の増加への対応

ECU統合 … 徐々に進行中

プラットフォームの共通化・標準化が前提に

パーティショニング技術が重要に

ネットワーク構成の複雑化への対応

• CANでは転送レートが不足しており、ネットワーク構造が複雑化する結果に

• 新しい車載ネットワーク技術の導入を検討すべき時期に

  短期的なソリューションとしてはCAN FDが有力

  車載Ethernetの導入検討が進行中

サイバーセキュリティの強化

• セキュリティ要求分析手法の確立
• 車載組込みシステムに向いたセキュリティ強化技術の開発／導入

---

情報通信技術と組込み技術による⾃動⾞の進化

---

自動運転前と自動運転後でどう変わったか

自動運転というものが急激に出てきたのはこの２〜３年。
自動運転の技術の出現の前と後でどう変わったのかについてもお話がありました。
現在、情報通信の技術や組み込みの技術によって自動車が非常に変わろうとしているということで、以下のような変化が見られます。

先進運転支援（ADAS）

●コンピュータにより高度な運転支援を行う

• 自動ブレーキ（緊急ブレーキ）
• 前車追従

つながるクルマ（connected vehicle）

●ネットワーク等により（情報的に）外部とつながる自動車

• インフラ（道路、クラウド）とつながる
• 他車とつながる、人（ドライバ、歩行者）とつながる

などが急速に普及しています。

自動運転（automated / autonomous driving）

●コンピュータにより運転を行う…急速に注目を集めている

• 周囲の状況をセンシングして、危ない場合は自動で止まる（自動ブレーキ）
• 一歩進めて走らせる、止まる

●技術的には、ADAS（Advanced Driver Assist System＝人を助ける）の延長線上にある

完全な自動運転になると、必ずしもADASの発展系ではない要素も

●「つながるクルマ」の延長線上にあるという考え方が主流

完全に自立して他からの情報をもらわずに自分のセンサーだけで単独で走るものもあるが、 非常にリッチなセンサーを積まないとできないので、 現在は周囲の情報を通信でもらって、それを助けにして、 もちろん自動運転を実現しようとしています。

●技術の進歩が著しいが、完全な自動運転には法的な課題がある

現在は各自動車メーカーが競争領域で、必死に作っているので各社バラバラで違うやり方を模索している状態。
それが一段落すると、技術を標準化しましょう、という動きが出てきます。 どの技術がいいか悪いかなどが評価できてくると、少し技術の幅が狭まってくるのですが、現在は幅が広がっている時期なのです。

---

自動運転に向けての組み込みシステム技術の変化

---

組み込みシステム技術に対する要求は自動運転システムの構成や実現方式によって大きく異なってくるので、今後要求が大きく変わってくる可能性があります。

---

機能の急速な高速化

従来の自動車の電子化は手足だったが、現在のコンピュータ化は人の頭脳をコンピュータに置き換えるようなものです。

---

外部接続の拡大

ダイナミックマップ … 車の自動運転や安全運転支援システムに必要となる、高精度の三次元情報を持つデジタル地図。基盤となるのは時間変化のほとんどない高精度の道路地図で、その上に比較的変化の少ない建物や標識などの情報を含むレイヤーが来ます。

---

ソフトウェアの柔軟な更新

更新によって機能アップデート、(s)OTA(Software update Over-The-Air)などでアップデートしていきます。

---

新しい技術の導入 急拡大する性能要件

AI、機械学習、Deep Learningなどの新しい技術を導入すると、これまでより計算精度、扱うデータ量が増加し、安全性に対する考え方も変わらざるを得ません。

従来の人が乗ってる自動車は、電子製品が壊れたら、メカは人に任せるといった感じでした。

自動運転で壊れた場合、人に運転させるということが通用しないので、壊れたとしても最低限、動き続けるという風にならないといけません。
サイバーセキュリティーの重要性も増しています。

自動運転／ADAS技術の動向とプラットフォーム

---

自動車に起こりつつある変化

---

自動運転の社会的価値

自動運転が可能になると、このようなメリットが考えられます。

• 事故が減る（安全性の向上）
• 移動中に他の仕事ができる（時間を有効活用）
• 公共交通機関がない地方でも移動手段ができる（高齢者・地方の移動手段）
• 人手不足の解消（隊列走行や無人配送で運送業の人手不足が解消される）
• 運転ストレスの低減
• カーシェアリングの有効利用
• 渋滞緩和

---

自動運転システムの技術構成

自動運転システムは次の大きく３つで構成されています。

認　知

周辺状況を認識する。

種々のセンサー[カメラ、LIDAR、ミリ波レーダー（長距離、中距離）、超音波センサー等]の組合せ

自分の位置を認識する。 重要

判　断

行動計画

どこを走るか決める。目標走行軌跡・速度、車線変更、合流

制　御

車を制御する（パワトレ、ステアリング、ブレーキ）

HMI（対ドライバ、初歩行者）

ーー「判断」・「制御」は中に入っているので外からうかがい知れない領域ですが、「認知」の領域は外からわかりやすいので、次に中でどんな判断をしているかを表した画像を見ながら説明がありました。
以下はセンサーの位置と名前を表したスライドです。

---

Audi A8のレベル3自動運転

AudiがA8という最高級車で、レベル3自動運転を販売するというアナウンスがありました。
レベル３自動運転とは責任が車にある、ということです。 今までの自動運転は基本的には人が常に看視していないといけなかったのですが、レベル３になると、自動運転システムが有効な間は車が運転席に移動します。
事故・トラブルが起こると自動運転がリバート停止する時があり、10秒以内にドライバーが運転権限をもってくれれば耐えられる、というシステムにしてあります。

---

ハードウェアプラットフォームの例

例）NVIDIA Tegra K1(GPU)より一つ新しいX1

もともとスマートフォンなどモバイル向けに作られたGPUですが、こちらを車に使おうというわけです。 コア数が256個、ピーク性能が512GFLOPS。

半精度だとその２倍。（半精度演算：最近機械学習などで計算する時そんなに高い数字はいらないということでどんどん制度を落としていく方法があり、半精度浮動小数点というのがありますがそれが２倍ということです）

普通のCPU：ARM Cortex A57という64ビット版のARMが使われています。

結構共通項が多く、どちらかというとアプリケーション向けのプロセッサであり、今までに比べて高性能なプロセッサを使おうとしているわけです。

ソフトウェアプラットフォーム

---

ソフトウェアプラットフォームも変わりつつあるとのことです。
現在、ROS（Robot Operating System）と呼ばれるものがよく使われていますが、AUTOSAR Adaptive Platform という新しい自動運転の新しいプラットフォームを作ろうとしています。

---

AUTOSAR（AUTomotive Open System Architecture)

AUTOSARとは2003年に発足した自動車業界のグローバル開発パートナーシップのことですが、車載電子制御システム向けのソフトウェアのプラットフォームの標準化、開発方法の標準化などを行なっている団体です。
この団体は、あくまで標準仕様（スペック）を提供するだけであって、それを実装するのは各社の構想であるというポリシーのもと活動されています。（高田氏の会社も）実装社の一つとして他社と競争して製品を作る立場にあります。

---

AUTOSAR Adaptive Platform

Adaptive Platformという新しいプラットフォームの標準化を始めるということで、活動が始まっています。

これはADASや自動運転を狙った新しいソフトウェアプラットフォームの仕様です。
従来のAUTOSARはAUTOSAR Classic Platformという名前に変わりました。 古いというわけではなく、役割の違いであって、今後も不要になるわけではないようです。

AUTOSARは、標準化を加速するために、従来は仕様書だけを作り、その仕様書を提供していたそうですが、現在はリファレンス実装の開発を並行して進めています。
非常にオープンソース的です。
（加入しないと仕様書は見れないので、現時点ではオープンソースではないがオープンソース的な開発をしています。）
従来、ある意味、保守的な自動車業界が乗り出しているのは、仮想的な敵はIT業界であるということが原因だといえます。

GoogleのようなIT企業が自動車業界に乗り込んでくる話もあり、今までの自動車業界のままでは、IT業界の企業にかなわないという危機感が自動車業界に起こっており、やり方を変えてきているわけです。これは非常に重要なポイントであると言えます。

他のプラットフォームとの使い分け（共存）

---

AUTOSAR CPとAPの技術的な違い

従来のAUTOSAR Clasic プラットフォームがOSEKという自動車業界独自のOSを使用していたのですが、AdaptiveプラットフォームではPOSIXを使うようになりますし、ROMからコードを直接実行していたところを、アプリケーションは不揮発メモリからRAMにロードされるなど、相当従来のものと考え方を変えてきていて、自動運転をきっかけに、割と保守的な自動車業界に新しいIT技術がかなり取り込まれていて、IT業界との競争が強く意識されていることが表れています。

TOPPERSプロジェクトにおけるmrubyへの取り組み

---

TOPPERSプロジェクトとmrubyの出会いは割と古く、2013年に九州工業大学の田中和明氏が軽量Rubyフォーラムを立ち上げる際に、NPO法人の作り方などそういう話から、技術的な取り組みも一緒にしましょうという話もあり、TOPPERSプロジェクトの中でTECSという技術と、軽量RubyフォーラムライブラリWGで協業を行うことになりました。

---

TECS（TOPPERS Embedded Component System）とは

TECSとは、TOPPERS Embedded Component Systemの略で、ルビコンシステム向けにソフトウェアを部品化してシステムを作ろうという技術です。
コンポーネントを静的に結合するーー普通のコンポーネント技術はコンポーネント同士を動的に繋いでいくわけですが、組み込みシステムの場合、全部静的に繋ぐことをやっていい、ということで、コンポーネント同士を静的に結合する、そうすると最適化ができるーーという技術です。

また、コンポーネントの実装方法ですが、普通のコンポーネント技術というのは、オブジェクト指向の発展系でコンポーネントになっている場合が多いのですが、TECSはオブジェクト指向ではないコンポーネント技術で、実装方法はC言語で記述します。とはいえ、オブジェクト指向のような要素はいっぱいあり、継承は持ち込んではいませんが、classとインスタンスのようなものがあります。

ちなみに前述のAUTOSARのClassic プラットフォームは、アプリケーションはソフトウェアコンポーネントの部品の組み合わせで作るので、結構、TECSとAUTOSARは技術要素が似ている部分があります。

---

TECS mruby Bridge Plugin

TECSで改良を続けている部分があり、TECS mruby Bridge Pluginというものを開発しています。
組み込みシステムの中でリアルタイム性が必要な処理部分があります。
例えばデバイスの中で、Rubyで書いていますが、リアルタイム性が必要な部分はCで書いた方が相性がいいというのがあるので、そういう部分はTECS（中身はC言語）で書くのですが、そのコードをmrubyから簡単に呼び出すことができるようにしようということで作ったものです。
TECSというのはソフトウェアの部品なので、それを呼び出すわけです。それをmrubyのプログラムから簡単に呼び出すためにmrubyのプラグインを自動生成するツールも作りました。

---

mruby VMのTECSコンポーネント化（マルチVM対応）

mrubyのバーチャルマシーンそのものを部品化してみようという試みで、mrubyのバーチャルマシーンをTECSのコンポーネント化することで、そうすると複数のmrubyVMを並行動作させることが可能になりました。
ただ、mruby自身はスレッド対応はされていないのでmruby同士の中では残念ながらできませんが、異なるmrubyVM同士を、リアルタイムOSのAPIを使用して同期・通信させることができるようになりました。 mrubyVMごとのヒープを分離しているので、一つのVMがヒープを使いきってガーベッジコレクタが走っても他のVMが関係なく動けます。（もちろん、その代わりメモリが各VMのヒープを分離しないといけないので若干無駄は生じてしまうかもしれないのですが）

---

---

製品化の事例

---

ツール開発へのRubyの適用

---

TECSのジェネレータ

TOPPERSの中で、ソフトウェアの部品の記述から、ソフトウェア部品を繋ぐためのグルーコードを作る、TECSジェネレータというツールがありますが、これはRubyを使って書いてます。約４万行くらいの規模です。

コンフィギュレータ

OSのコンフィギュレーションを決定するツール、これもRubyを使って作っており、大きいのは１万行くらいの規模です。

---

車載組込みとmruby

車載にRubyを使いたい。
しかし、やはり、車載制御システム分野は、安全性に関わるものが多いので、品質要求が非常に厳しいので、中々新しい技術を使用することは厳しいです。

AUTOSAR Adaptive プラットフォームにも、ITの世界の技術を車の中に使おうという試みは世界的に自動車業界で考えられています。

---

狙うべき領域は？

まずは、安全性の関わらない領域から。
典型例：IVI（車載インフォテイメント）

mruby（組み込みシステム向けスクリプト言語）の特性が活かせる領域はどこか？

やはり、ソフトウェアをガッチリ固めるのではなく、頻繁に修正したいシステムだと思われます。

• 車両の個人化（パーソナライズ）、おもてなし機能
• 自動運転のシナリオ作成

まとめ

車載組み込みシステムとmrubyを結びつけることは、高田教授の頭の中でもまだまだできていない、との前置きから始まりましたが、自動車産業に大きな変化が起こっており、それが、IT業界の影響が多大にあるということがわかりました。
自動運転の可能性は私たちのこれからの生活の中に密接に関わってくる問題なので、とても興味深い研究・開発だと思います。
この研究・開発がさらなる発展を遂げ、自動運転が普通のことになるのも、もうそんなに遠くない将来ではないでしょうか。
RubysitBizでは、今後もmruby、そしてTOPPERSプロジェクトに注目し、レポートしてまいりたいと思います。

---

【Vol.03】はここまで。
まだまだ続きます。