********************************************************************** セッションS1-d 夜の分科会テーマ：若手研究者によるお悩み相談室　　　　〜この先端研究ってホントに産で使えるの？　　　　この最新技術ってホントに学で扱えるの？〜コーディネータ：高瀬英希(名古屋大学) 日時：2010/09/02 20：45-23：00 参加人数：約20人（開始時），約50人（終了時） ********************************************************************** ■オープニング夜の分科会S1-d、「若手研究者によるお悩み教室〜」というタイトルで分科会を始めたいと思います。よろしくお願いします。（拍手）最初に聞いておいた方が良いと思うのですが、学生というか若手研究者だと思う方の挙手をお願いします。そうではなくて産業界の方の挙手をお願いします。では、学の偉い方の挙手をお願いします。（各自挙手）だいたい学生というか若手が半分以上ということで、もう少しいじめてくれる人が増えたら良かったかなと思います。では、私の自己紹介です。愛知県の北西の方の出身です。2003年に大学入学し、 7年近く同じ大学にいます。2006年3月に研究室配属され、この業界に組み込まれました。入った当時は組込みという単語すら知りませんでした。この研究室を選んだ動機としましてはコンパイラを研究できると聞いたためです。そして、 2009年に博士後期課程に進学しD2で現在に至るとなっています。補足としましては、SSEST4の実行委員長を務めさせていただきました。このセッションでやりたいことは、とりあえずお酒を飲みましょう。とにかくざっくばらんに議論をしましょう。人材交流を促進する場でもありますので、仲良くやりましょう。酒のつまみとして若手研究者の抱える悩みを用意しました学の悩みをあげてみました。一番大きなものは、研究をやっていて、産でニーズがあるのか？ということだと思っています。他にも、産のニーズはどこにあるのか？、それをどう知れば良いのかというところも悩みだと思います。この場で産の人々と仲良くなってそういったところを引き出せていければ良いかなと思っています。産の悩みは想像でしかないのですが、学で何をやっているのか？という点かと思います。反論があれば言っていただければありがたいです。また、活きの良い学生、即戦力になる学生がどこにいるのだろうか？ということだと思います。おそらくSWESTに来ている学生が即戦力となると思います。本セッションで期待する議論像としましては、産の悩み、学の悩みを出してみようというものです。4名の若手研究者に自分のやっている研究を説明してもらいます。自分のやっている研究が本当に産で使えるのだろうかという悩みが出てきています。産の悩みも出てくると良いと思いますが、どうしたら景況や部下とのコミュニケーション等は学に求められても困ると思うのでNGでお願いします。本セッションの進め方としましては、前半は若手のライトニングトークを、後半は話題ごとにテーブルを作って討論をする予定です。場の空気で変わるかもしれません（後にテーマごとに全体で議論する形に変更）。時間切れになったら徹夜部屋に移動しましょう。議論テーマは、リアルタイムOS、ソフトウェアモデリング、システムレベル設計、低消費電力設計の4つです。飛び込みも大歓迎です。 ■ソフトウェアモデリング ▽ライトニングトーク分野的には、ソフトウェアモデリングforエンべデッドシステムといった感じです。今、既にD4ということでそれだけで悩みをかかえている感じですね。自己紹介です。モデリング技術を道具に研究をやっています。組込みは趣味であり、研究対象でもあります。対象としては基本的にソフトをやっています。その他、留学生向けの日本語教育の補助のシステム作成をしてます。道具としては、モデル駆動型〜、ソフトウェアプロダクトライン、アスペクト指向、オブジェクト指向は一通り押さえてます。学外では、SWESTの実行委員、Eclipse のコミュニティのメンバーです。趣味は、組込み関係のおもちゃを買ってきたり、部品をばらしたりすること、猫好き、茶道です。研究背景についてです。組込みソフトは大変だよという話を聞いてまして、同期が組込み業界で働いていますが、日付変わってもなかなか帰れないのが多いと聞き、なんとかしたいということが基本動機です。HWがらみの部分、いろんな制約、ソースコードの最終的に書かれた一行が何を意味しているのかわからない等、そういうのがあって、組込みソフト開発って大変なのかなと思い、研究を始めました。もうひとつ嫌なことは、電子データを人が読まなきゃいけないことです。せっかく電子化したのだから機械に読ませて自動化してしまおうと思い、モデル駆動を始めました。ドメインの情報をモデル化してコードまで落としたいという事をメインに研究しています。形式使用記述言語で書くという方法もあるんですが、書くのが大変なので、モデル駆動記述がほどよい妥協点になるのかなと思います。研究では、データシートや回路図を基にメタモデルを作って、モデル化し、コードにするということをやってます。相談したいことは、現場ではどんな情報が流れていてどのような開発が行われているのかの様子等を聞きたいと思っていました。また、みなさんに使ってもらうにはどこまで一般的にすべきかなどです。相談を受けることとしては、開発全般やモデル化や自動化などです。 ▽質疑応答若手：モデリング(UML)を使っている人いますか？（数人が挙手）UMLからソー　　　スコードまではどうしてますか？会場：もちろんコード生成器を使っています。会場：モデリングはソフトが大きければメリットがあると思います。大学でや　　　ると、大きなものを用意するのが難しいと思われる。適用するターゲッ　　　トは大きい方が良いが、大きいものはとても学では扱い切れない。その　　　あたりのジレンマについてはどう考えていますか？若手：いろんなターゲットや規模を試さないといけない、規模を確保しないと　　　いけないので、データシートをできるだけ多く集めていろんなものに試　　　してみてます。あと、ソフトウェア規模は大きくできないのが現状でし　　　て、オープンソースを探しているが、組込み関連のオープンソースがな　　　かなかないものでどうしようかなというところです。会場：現場にモデル駆動を導入するとき莫大なレガシーが必要だという問題で、　　　最初にリバースモデリングをやる際に、良い協力者を見つけられるかが　　　大切で、たまたま良い協力者に出会えて、データをもらえました。若手：ソースコードを提供できる方いらっしゃいませんか？モデリングしてあ　　　る程度リファクタリングしてお返ししますので。司会：どうやって見つけられたのですか？会場：高専の先輩でした。司会：見つけるためのテクニックはありますか？先生に頑張ってもらうしかな　　　いですかね？会場：サイズをあまり気にしなくてもいいのでは？という気がします。今は　　　何Mかというのをやってるけど、しばらく前は十Kほどあれば十分だった。　　　炊飯器とか割と小さいものを扱っているのではないか？と思うのですが　　　どうでしょうか？あるまとまったところで、どうなっているのかが大事　　　ではないかと思います。若手：小さい規模でも使える例題はどこかにありますか？自分で作るしかない　　　ですかね？会場：MDDロボチャレがあります。ETロボコンよりは難しいと思います。若手：モデルサイズはどのくらいなのか？会場：10クラスほどだと思います。若手：仕様については公開されていますか？会場：公開されています。会場：日頃、一品もののソフトを作ってます。ソフトウェアが一般に出るもの　　　なのか、高級品なのかで開発手法が違うと思うので、組込みといえども、　　　標準化したいとか、したくないとか、標準化すると安くなるが、一品も　　　のだとお客様に毎日聞きに行く形になるが、ターゲットをどこにすえる　　　かで変わってくるのでは？と思います。若手：今のターゲットは小〜中規模です。はやく開発をしなければならないも　　　のを考えている。会場：サンプルコードを渡してくれるパターンがほとんどなんです。データ　　　シートを渡されてイチから作るという場合は少ない。たとえばLinuxのデ　　　バイスドライバを作ってあるので、という場合が多く、品質はアバウト　　　なところがある。モデルをゼロからつくるのは難しく、研究と実際の　　　ギャップがある。もしかしたらメーカーよりチップセットメーカーとか　　　にアプローチした方が良いのでは？司会：派生開発に似た話になってきてます。ゼロから作るのはほとんどないと　　　いう。会場：ぜひ半導体メーカーにアプローチを。若手：最終的には、そこをねらってます。業界をつなぎたいと思ってます。司会：この場に半導体メーカーの方はいませんかね？会場：グループ内で作っています。本体に来ても良くはないかなと思います。司会：その企業への橋渡しはやっていただけますか？会場：それは勘弁してください。若手：データシートをつくるもとの情報にアクセスさせてもらえますか？会場：アクセスできるような状態で公開されているかどうかはわからないです。会場：モデリングとかに関して学にお願いしたいことで、迎合するのではなく、　　　こうだと言ってほしいというのかあります。高級言語を書いてるものは　　　計算モデルが前提とされてます。どんなモデルでどんな側面を記述して　　　いるのかが異なる。ある業界では、モデリング言語が使っていると言え　　　ば、ほぼsimlinkを表していたりします。学側が説明することが意味が　　　あると思います。実はモデルは既にあり、ある書き方をすればできるは　　　ずです。丁寧な説明をしてくれる学の方があまりいないのでそこを期待　　　したいです。若手：会社ごとであるというのはわかりますが、学側がこういうものだと言う　　　のは難しいです。こういうドメインがあってこういうプロセスがあると　　　示していただけるとありがたいのですが。会場：お前ら気がつけというのが学の立場だと思います。結局やってるのはこ　　　ういうことだよね、余計なことを書いてバグの温床になるんじゃなくて、　　　本当はこういうことをにやりたいんだよねと言い聞かせてあげることが　　　学の立ち位置として良いと思う。若手：そこを研究するためには、ソースコードを提供していただけると助かり　　　ます。インターンシップに見せてもらってリバースしてという研究をし　　　ていたが、すごい属人性が3種類くらい混じった100万行のコードでモデ　　　ル化が難しかったのですが、パターンが見えてきたので、いくつか見せ　　　ていただければまとめられるのではと思います。 ■低消費電力設計 ▽ライトニングトーク LSIの内部回路について研究しています。実装設計の特にPowerGating(PG)について説明していきます。先輩方の胸を借りていきたいです。まず、自己紹介です。研究室配属時からPG回路の設計に携わり、ゲートベース PG回路のメソドロジやLIPR3000のチップ製作などをやっています。PG回路の最適化に用いていたCADツールでの遅延が悲観的な値を出してしまいます。それであれば遅延時間解析をしようと思いました。ちなみに回路設計をやられている方（1名挙手）、PG回路と言われてピンと来る方（数名挙手）、では細かい話は割愛で。低消費電力設計の基本方針として、ダイナミック電力とリーク電力があります。ダイナミック電力を下げる一番の方法は電源電圧を下げる。もうひとつは、必要のない回路に入力信号を与えない、動作させないことです。これは、クロック、オペランドに信号を伝えないということです。メインにしているリーク電力削減は、しきい値電圧を上げることが根本的解決です。低消費電力技術として、ダイナミック電力削減とリーク電力削減にそれぞれあり、リーク電力削減方法のPGについてどんな研究が学でなされているか産ではどうやっているのかを説明します。 PGの主な目的は，回路が利用されない時間に電力の供給を遮断して、リーク電力を削減する手法です。論理ゲートはしきい値が低いため高速ですが、リーク電力が大きくなってしまいます。そこで、グランドと論理ゲートの間にしきい値の高いトランジスタを挟みこむことによって、トランジスタONしているときは存在が見えないようになり、トランジスタOFFすることによりリーク電力をカットする技術です。学によるPGの研究では、回路方式があります。スリープトランジスタの作り方や強制的にOFFの力を強めたり、トランジスタを強めたりする。回路が使用時に抵抗が存在するので、遅くなってしまうので面積が増えてしまわないよう改良する研究や、モード切換の高速化があります。学では、細かい部分に着目したアプローチになっています。一方、産によるアプローチはCPUで作ってしまっています。コア単位での実装されています。私見としては低消費電力に関する個々の回路技術の研究はだいぶやりつくされていると思います。その理由に、最新のCADツールに組み込まれているというとがあります。残された課題としましては、制御の単位をより細かい範囲で行うこととシステムレベルでの設計で精度の粒度の決定を自動化することで、設計複雑度のモデリングが必要だと思っています。その際、実際に企業等で行われている方に回路のサイズなどの制約について生の声を聞きたいと思っています。最後に、具体的なアルゴリズムに特化した回路への応用があると思います。専用HWに関しての最適化が大きなテーマになると思います。たとえば、回路の使用パターンに応じて先読みを利用することや、制御にかかるデメリットを回避するなどが考えられます。これはアプリケーション開発をしている人の意見をきいてみたいと考えています。 ▽質疑応答司会：低消費電力に関する研究は学で盛んに行われているが、そのどこに向か　　　っていくのか？会場：やりつくされた感があっても、半分にしたければ、まだやらないといけ　　　ないと思います。それは延長線上かもしれないし、もうちょっと大きな　　　発想の転換が必要かもしれないと思います。会場：この手の話は石を設計する人だけがいくらやってもダメなのでは？それ　　　だけ考えていてもダメだという気がします。いくら石が良くても、使わ　　　れ方が変わると変わってしまうと思います。システムとしてどう見るか、　　　予測して云々と言っていたがどうやって予測するのか？だと思います。　　　たとえば、季節変動を予測できるか？若手：その予測はできないことも多いです。会場：経年変化で、需要が増えて通信量が増えてという場合があります。石屋　　　だけでは難しい、限界を感じました。会場：学でも産でも求めるのかゼロです。太陽電池などその場で取れたらそれ　　　でもいいです。どういう研究を求めるかではなく、ユーザとメーカーは　　　答えしか求めないです。どこに向かうべきかというよりは、何mAにすべ　　　きかという言い方があれば、産業界が数値に関しては学に頼るところが　　　大きいです。どういうやり方をしたらいいのかより、どういう値を出せ　　　ばいいのか？を聞いていただければ、答えをズバッと言えます。若手：では具体的にどれくらいが良いでしょうか？会場：私のやっているところではないが、スマートメーター関係をやっている　　　部分があります。私のところはたかが何mA減ろうが正しく動くことが大　　　切というところだが、スマートメーター関連では、つもりにつもって何　　　万世帯という規模になるとかなりの電力になるので大損となります。な　　　ので電力制御に需要があるのでは？と思います。携帯だけでなくそのよ　　　うな実際にお金になるものをねらってみるのもおもしろいと思います。若手：みんなに使われていて、まだ目につかないところですか？会場：実際にお金が出てって苦しいところです。ホームゲートウェイでは性能　　　さえよければあまり気にしてないが、実際にお金が出ていくところはす　　　ごく気にしています。会場：使う側の意見ということで、現場でやってて何が問題かというと、でき　　　ることはわかるが、誰が検証するのか？という点です。非同期系の検証　　　は難しく、それをどうやって検証するかはほとんどないので、検証を　　　やってほしいと思います。　　　頻繁な切換はIRDROPでシステムで動かなくなることがあるのでそれに関　　　する研究もやってもらえたらと思います。若手：現場からの意見ありがとうございます。検証は研究室では問題になって　　　いるがどうやれば良いのか検討がついてなく手がついてない分野なので、　　　需要があることが再確認できたのでなるべく考えていきたいと思います。　　　IRDROPについては、研究でいくらかされている部分があって、時間差を　　　つけることなどがあります。信頼性がPGは怪しい部分があるのでその点　　　は非常に気にしていきたいところです。 ■システムレベル設計 ▽ライトニングトークディスカッションのネタ提供ということでやらせていただきます。お悩み相談ということですが、そんな悩んでいるように見えたのかなというのが釈然としないのですが、毎日楽しく生活しています。自己紹介です。1981年生まれで、2009年3月に博士号取得、現在助教です。博士課程時に海外の研究所に10ヶ月ほど留学し、良い経験をしました。この話が来た縁として、SSEST1,2の実行委員をやっていたということがあります研究背景について説明します。システムレベル設計という話があったと思うのですが、設計空間探索について研究しています。背景としては様々な設計ツールが存在し、自動生成が可能になっています。しかし、ツールが出たところで実際に設計する人は楽になっているのか？という疑問が発端です。高速に評価できるとか設計可能な範囲が広がる等と論文には書かれます。現実、使っている側はどう感じているのかというと、良い解を出してくれないから困ると言っていました。この方々は、こういう解がほしいなというのがあって、そのような解が出てくるように入力を与える、という設計と評価の膨大な繰り返しが行われています。設計空間探索とは、与えられた設計空間から最適な解を探すことです。分野に限定された話ではありません。例えば、組込みでもいろんな制約があると思います。その実現方法は山ほどある中で、それぞれが違う実現方法を行います。その中からほしいものを見つけ出すこと、空間の中を探索するということになります。そのとき、最適とは何か？という話になります。例えば、性能が必要なものは電力に目をつぶります。携帯では性能は最低限このくらい出してほしいけど、電力は小さくすることが絶対要求となると思います。制約は本来、設計者によって決定されるものです。ここでpareto解の探索が重要になります。今までは、作ってみよう、その結果をみて、じゃあ変えてみようを繰り返し、空間の中をひたすら迷っていることになります。私の研究では、いかに楽するか、自動化するかということをやっています。具体的には、あきらかに悪いものを削除し、解空間を狭めるということをしています。また、評価も何回も繰り返すことになるため、性能の見積もりや消費電力の見積もりもやっています。設計空間というものは、大きい空間の中にすべての解を求めるもので、際にある解をpareto解と呼びます。これよりも良い解はないという解となります。その中から制約を満たす解を見つければ終わるはずなので、最適解をいかに効率よく見つけることができるかを研究しています。最適な構成を探しなさいという問題において、解の候補が3万とか4万とかになってしまいます。あきらかに無駄な部分を削除することで、探索時間で160倍以上の高速化が実現できました。考え方としてはこのようなことをやっています。　ここには、DAシンポジウムのかたもSWESTの方もいると思います。最近興味があるのは、設計の手戻りです。何か作った評価したと繰り返すのは手戻りだと思います。設計空間探索の完全な自動化は可能なのか？と考えています。対象は明示しません。また、設計空間探索の自動化が実現できたとして、もうなくなったとします。そのとき、設計者にとって本質的な作業、すなわち、設計とは何か？と考えます。ツールを開発してこうしたら手間が省ける、いいものつくれるとなると、どのように差別化するのかと考えてしまいます。結局、設計とは何か？というのが最近の疑問です。最近の悩みというかは、産の話はまだまだわかりません。手戻りに関してはそもそも現場ではどれくら困っているのか？そのような事例はどれくらいあるのかな？自動化できないのかな？実際に使ってもらえるのかな？と疑問に思います。いろいろなネタを提供していただければと思っております。 ▽質疑応答会場：30年くらい前のあるところを思い出しました。もともと数値計算、電子　　　回路やってました。アナログからデジタルに変わった当時と非常に似て　　　いると感じました。評価関数がちゃんとわかってるとそれに最適なもの　　　を選べたのですが、デジタルになった途端に選べなくなったというのを　　　思い出しました。　　　もうひとつ、ある評価面に近いものとおっしゃっていましたが、それ自　　　身がをうまく定式化できるのだろうか？それがうまくできないからこそ、　　　トレードオフの関係にあって、こんな感じでってやるんです。評価関数　　　をどう定義できるかがポイントだろうなと思いました。若手：評価関数に関しては大変難しいところがありまして、例えばシステムに　　　なった場合に振る舞いは変わります。一概にこの場合はどうだといいき　　　れないです。会場：条件によって変わるし若手：これはこうだといいながらも結局こういう条件で少なくても目安として　　　ある同じデータを与えたときにどれくらいであったという話で、絶対に　　　ふるまいを予測できるわけではなく、あくまでも参考です。ただ、その　　　精度があがれば効率化されるのかなと思います。会場：絶対とらないというのをどう捨てるかということかもしれません。若手：こういう研究をしているときに、何をしたいのかと悩んでいました。そ　　　もそも設計において、良い解と悪い解を区別できるのか？と思いました。　　　性能は良いけれども電力がかかる一方、性能は劣るけど電力は低い、と　　　いう場合に選択できないと思うのです。会場：それを決めるのが評価関数だと思います。若手：それは設計制約と捕らえてます。会場：どういう条件でどう定義できるのかがポイントになると思います。若手：僕の解釈で説明させていただきます。良い悪いという議論をした際に、　　　性能も電力という軸のみで考えた場合、共に悪いものは選択する必要が　　　ないだろうと思います。軸が増えたらまた議論をするポイントだと思う　　　が、本質的にはそこまで変わる話じゃないと思います。設計する人がど　　　ういう軸を考えるかを固めることが大切だと思います。会場：なかなか難しいですね。その考えを大事にしてください。会場：設計制約と評価関数を混ぜて話されてました？会場：はい。混ぜてしまいました。会場：設計制約自体もお客様の要求であります。どこに使うかで変わるものだ　　　と思います。若手：企業ではお客様があるが、学としてはどこにでも役にたつものができな　　　いといけないと思います。そこでpareto最適が大切だと思います。これ　　　より良いものはないのであとはお客様で選んでくださいと極論として考　　　えています。会場：企業と学を区別する必要はなくて、自分以外の人間に何を求めるのか？　　　だと思います。低電力や効率化といった際に求める人がいると思います。　　　グラフが求めているのではなく、人が求めているんです。このグラフは　　　どなたが求めているのか？産であっても学であっても人があってのシス　　　テムだと思います。人は人はに持っていかれるとより良いのではないか？会場：要求された評価関数ではなかったのか？若手：設計というものが与えられたとき、いろんな評価指標があると思います。　　　LSIなどでは、まずは性能、電力、面積が三大指標として出でくるので、　　　そこからスタートして満たされることが、われわれの業界としても絶対　　　です。別の指標がでてくることも、人が望むことが新たな軸で入ったと　　　きも、そこでも最適が存在すると思います。逆に、人からどんな評価軸　　　が出てくるのかに興味があります。会場：メーカの永遠の課題であり、答えはないです。　　　デザイン工学的に言えるはずだというものである若手：そこでいうデザインとは設計という意味ですか？見た目のデザインとい　　　う意味ですか。会場：両方です。民衆が求めるものと工学が求めるものがずれます。若手：例えばipodとかを見ててもそうですよね。インターフェースとか見た目　　　がかっこ良くでも、いろんな機能を足せるのにというなかなか難しいと　　　ころですね。会場：否定も文句も言うつもりはなくて、ヒューマン的な要素を活用できれば　　　相乗効果で良いと思います。会場：そのような要素というのはシステムをつくる上ではとても大切だと思い　　　ます。ただ、設計空間探索と要件から落とし込むというのは別の問題だ　　　と個人的に思ってます。全く見落としてやるのは間違いだと思いますが、　　　ある程度関心の分離を行ってそれぞれにおいて問題を解くというアプ　　　ローチは悪くないなと思います。よってあれ（提示されている図）はう　　　れしい絵だと思います。会場：ちょうどこのような絵を見て議論していました。パレート最適はあたり　　　まえで、次の課題はパレート最適解がたくさんあるときどうするのか？　　　人間が見たらわかるが、どうやって選ぶかが課題になるのではと思いま　　　した。若手：パレート最適の話になったときいつも思うことなんですが、今回の設計　　　における軸を明らかにすることが大切だと思います。ここではサイクル　　　とエリアと電力の3軸。私の考えでは、いくらあったとしても設計制約　　　やりなんなりでえいやと切ったときに一番コストの小さいものが最適解　　　になるのではないかと安直に考えています。会場：制約はあることはある、ユーザの要求が曖昧なこともあるので、pareto 　　　最適という考え方が重要だとは思いますが、どこをとるかが難しいと思　　　います。若手：少なくとも選ぶべき解はpareto最適の中にあるということです。そこか　　　らどう選ぶかは。会場：お客様の要求をエンジニアリング可能な値や制約に変換してそれを満た　　　すようにどれかを選ぶしかないと思います。それはまさにソフトウェア　　　工学が求めている要求工学に突入してしまうのではと思います。私はQFD 　　　やられると良いかなと思います。若手：ある学会用に出した実験では、あまりpareto解がでないんです。3つと　　　か4つとかで、たくさん出る例は新鮮でした。問題が単純というのもある　　　と思います。会場：まっすぐなここが斜めだとたくさん出るんです。若手：コスト関数の定義の仕方かなと思います。制御がちょっと入ってくると　　　揺らぐのかなと思っています。本当に単純なグラフを実行する場合です　　　ので、サイクルごとの結果になっているのだろうなと考えています。全　　　体の実行時間が長いときにいろんなものが出るのかなと考えています。　　　システムの規模が大きいと思うので、我々の評価実験やる際にはMPEGの　　　この部分でやってみようというような形になります。その辺で実際とず　　　れるというのはあるかもしれないです。 ■組込みシステム向けリアルタイムOS ▽ライトニングトークソフトよりのリアルタイムOSを研究しています。産の方との交流が少ないので、いろいろと議論できたらと思っています。自己紹介ですけど、組込みシステムの研究員で主に自動車のやソフトウェアプラットフォームの研究開発などをしています。個人的には、アルゴリズムよりで、OSの開発、TOPPERSのOSの移植や，アプリケーションの設計に使用できるスケジューリングシミュレータを作っています。最近の学生や企業の方がどれくらい興味を持っているのかがわからなかったので自分なりに表してみました。規模が小さいレベルではお手製につくるものもまだ世の中にありますが、規模が大きくなると購入してアプリケーションに注力していく方向になっています。OSに人をつぎ込むことが重要でなくなっていて、他に知恵を注いでいる傾向があると理解しています。注目したいのは、研究しているカーネルやOS辺りは比較的手を入れやすいものもあり、先行プロトタイプ開発などいろいろなことができます。技術者がたくさんいれば自分たちで好きなものを作れます。特に日本のOSベンダは少ないので、OSを作る時代は過ぎ去ったのか？という感じもしますが、まだまだやることはあるよねという位置づけになります。 OSに関連する課題ということで、OS以外にも重大な要素があると思っています。 HWの高機能化により競争がOSからアプリに変化し、大規模化しています。また、安全性が大事で、監視や異常検知などのリカバリ機能が多くなり、本来満たしたい機能と同程度かそれ以上の重要性に高まっています。そのとき、プラットフォーム側でできることは何かと考えています。アプリケーションが主役であり、それを助ける機能を考えた際、なるべく共通化したいものがあれば、研究組織がやれれば役立つのでは？と考えています。私の個人の研究テーマについてです。OSの基本的な仕事は仕事を振り分けることです。いろんな仕事をどうやるかがスケジューリングの基本です。そのポリシとして優先順位をつける、デッドラインが早い順にやるなどが考えられます。それぞれが学問的に確立され、固定優先度ベーススケジューリング、ラウンドロビンなどがあります。それに対して仕事の分野ごとにCPUのパーセンテージを割り当てるリソースリザベーションを研究しています。これは時間の保護とも呼んでいて、仕事を分類しそれぞれに割り当てます。大きく考えるのは大きな分野でのみ考え、細かな部分は気にしません。それぞれの部分をスケジューリングする人がそれぞれのポリシで行います。こういうものを階層型スケジューリングと呼んでいて、研究はいろいろなところでやられています。例えば、VMにOSがたくさんあるとそれぞれにスケジューリングされているなど、いろんな場面に適用できます。特に車のアプリケーション統合で行われています。それぞれの部品メーカーが作っているものを複数合わせてひとつのコンピュータで動かす場合に、全体の仕事としては上手くいくようなアプリケーション統合を研究としてやってます。各アプリケーションのデッドラインを満たしながら、オーバランした仕事やバグなどが別の仕事に影響しないように壁をつくります。このような話があるとアプリケーション開発が容易になるだろうと主張してます。開発側はOSやプラットフォーム選び、こういう機能があると便利だよねという視点でやっていると思いますので、現在のリアルタイムOSやソフトウェアやプラットフォームに求められる機能について議論したいです。そして、皆さんの組織で開発された有能な機能を紹介してほしいです。また、OSを選ぶ基準について技術者が少ないので高機能なOSを選べないなどの問題がありますが、ソフトウェアプラットフォームという視点で議論させていただければと思っています。 ▽質疑応答会場：自動車制御ソフトウェアでFlaxRayとか研究しています。リアルタイム　　　OSにあったら良いなという機能にAUTOSAR4.0のパーテショニングやメモ　　　リ保護などがあります。あの機能が大事だと思いますが、一般的に考え　　　て性能が落ちると思います。どれくらい落ちるかが全くわからないので、　　　オーダーレベルでもわかれば教えていただきたい。　　　もうひとつ、タイムトリガにガジェットを割り当ては良いなと思います　　　が、実際量産には反発する方もたくさんいらっしゃる。どうやったら説　　　得できそうですか。若手：パーテショニングという話なんですが、機能安全や、AUTOSARの自動車　　　でも高機能なOSのスペックを指定されているものもあります。現場では、　　　ソフトを作る方からすると、区切ると考える人が増えることと切り替え　　　時間が増えることによりオーバヘッドが増えると言われています。メモ　　　リ領域については、HW化することによってオーバヘッドが減らせます。　　　HWの変更は一種のしがらみがあるかと思いますが、これも一つの提案で　　　す。　　　SWのリソースをパーテショニングするというのは、研究としておもしろ　　　い話で個人的にはホットだと思います。作ってみてやってみないといけ　　　ないと思い、オープンソースのOSを使ってオーバヘッドの測定をやって　　　みた結果、2倍弱になりました。　　　オーバヘッドが大きいことがなぜ問題なのかをアプリケーション開発者　　　から提示してもらえるとありがたいのですが、なんとなく大きそうだよ　　　ねというのだと難しいかなと感じています。アプリケーション開発側か　　　らの意見を聞かせていただきたいところです。　　　2つめについては、海外では飛行機とかで使っています。お金が使える　　　ところでは、パーテショニングが使われている。それは機能がすぐれて　　　いるのか、規格に準拠されている、サポートしてくれるからなどいろん　　　な理由があると思いますが、機能は商用のものと同じくらい満たしてい　　　るので、アプリケーションをこちら側から提案していくのが最適な方法　　　かなと思っています。学でできることなのかと感じているので、企業の　　　方と協力して、ロボットなどのアプリケーション含めてやるしかないか　　　なと思います。会場：ロボット向けリアルタイムOSの作成しています。自動車向けとロボット　　　向けとはどのような差異を持たせるべきとお考えですか？若手：自動車に関してもマイコンの性能をみるとギリギリの範囲でやられてい　　　て、OSEK仕様のものを見るとメモリ要領を少なくしようという努力がさ　　　れています。これからのことを考えると、パーティショニングなどの機　　　能を追加していく必要性があるでしょうという過渡的な状況だと考えて　　　います。会場：メモリが増えていくから制限しなくても良いということですか？若手：制限しなくても良いというよりは、自動車向けには壁をつくる機能がほ　　　しいのかなと考えています。　　　ロボットの場合には良い性能のマイコンを使っていますよね？会場：スペックが高いものを使う場合もあります。若手：画像処理とモータ制御を同時にやるなら、OSの機能としてパーティショ　　　ンもありかなと思います。会場：分散制御型のロボットを考えていまして、個々のモジュールが協調動作　　　をするものを想定しています。その場合、ひとつのCPU内でモータ制御　　　なり画像処理なりをする必要性がでてくると思います。若手：画像処理などの役割分担ということになると思います。会場：画像処理は自動車でも人の検知などで使うだろうと思います。そのこと　　　を考えるとロボットと自動車の境はどう引くべきか？若手：非常に難しい問題ですので、徹夜部屋に行きましょうか。共通化できれ　　　ばいいかなと思いますが。会場：共通化できる部分もあるでしょうし、どこかに違いがあると思いますが　　　そこをどう引けるのかという疑問があります。若手：すぐに結論が出る話ではないです。一家に一台とか一人一台になってく　　　ると安全性、価格コストの問題も考えられます。会場：どこまでが家庭用でどこからが産業用でという点も疑問に思うところで　　　す。 ■まとめ SWEST/DASの共催で行われた、産学連携の場でもあると思います。現場の生の声を聴けるという良い機会だと思っています。発表者も貴重な意見をきけたのではないかと思います個人的にはおもしろかったので，来年もやりたいと思っています。今から募集しておきます。来年もやるのであれば、産の方からも話題が出せれば、よりおもしろいのではと思います。