********************************************************************** セッションS3-de チュートリアル テーマ:Interface連載記事で書ききれなかったこと 講師:佐藤 洋介 氏/山郷 成仁 氏(デンソー)    間瀬 順一 氏(アイシン・コムクルーズ) 日時:2009/8/28 10:30〜11:50 参加人数:30名弱(終了時) ********************************************************************** S氏:本セッションではインタフェースで書ききれなかったところを説明します. <会社の方が直面する課題について> ○現状のよくある問題  ・過去の設計レビューで検討しているはずだが,突然の設計の変更の影響が不安である  ・検査項目きちんと網羅されているかどうかが不安  ・実績のあるソフトウェアを再利用したら,思わぬ落とし穴があった  などがある. ○課題に対する解決策  ・正しく変化点と変更点を確認できていれば良い.    ⇒変化と変更を正確に記述する    ⇒組織として,レビューが適切に行われていればよい.    ⇒この2点が重要となる. ○正確に仕様を記述する,とは   ⇒正確に書くことと詳細に書くことは異なる.   ⇒正確に書くとは,解釈に誤解が発生しないような記述をすることである.  数学的な宇和付けのある記述方法 モデリング言語が利用されている.  モデリング言語は,要求/アーキテクチャやネットワークなどの各種類に応じて  多くの種類がある. S氏:本日の趣旨として,要求の変更点による,設計/実装の変化点をきちんと   押さえる手法について討論したいなと思います.   <車載ソフトウェア開発の現状と課題> S氏:Autoserとは何なのか,何故これらができたのかについて説明していきたいと   思います. ○カーエレクトロニクスの分類  ・パワートレイン制御  ・情報通信  ・シャシ制御  ・ボディー制御  ・本セッションでは,パワートレインとシャシを中心に討論していく. ○カーエレクトロニクスの歴史  ・70年代から排気ガス対策をするようになった.    ⇒この頃から徐々にカーエレクトロニクスが始まった.  ・70年代後半からマイコンを用いるようになった  ・90年代にはこれらが高機能化され,  ・00年代にはネットワークを用いられるようになった.  このような流れに伴って機能が複雑化してきている. ○高機能化の事例  ・Vehicle Dynamics Integrated Management    ⇒どんな路面状況でもドライバの操作を支援して,安全性と高運動性能を実現     するシステム    ⇒これまでここに独立して制御していたエンジン・ブレーキ・ステアリングを     同時に制御 ○ネットワーク化の事例  ・車で使用されるプロトコルは非常に多くなってきている    ⇒それぞれの種類に応じて用いる ○車載ソフトウェアの特徴  ・組込みソフトウェアとしての特徴    ⇒ハードリアルタイム性,省リソースが求められる    ⇒納入先との分担開発を行うことが多い ○分担開発のプロセス  ・アイディア→制御仕様設計→仕様分析→ソフトウェア設計   →コーディング→デバッグ→テスト→実写評価  ・サプライヤが担当する範囲によって分類がなされている    ⇒上の全体を通るもの   :タイプA    ⇒使用分析からテスト   :タイプB    ⇒制御仕様設計からテスト :タイプC M氏:数が多いものはタイプCに.数が少ないものならタイプAになります.    会社としては,自分たちがどのタイプで受注すれば良いかを確認する必要は    あります.  ・タイプCはあまり責任を感じないようなことがある.  ・タイプAは責任を多く受け持つことになる. ○車載ソフトウェアの現状  ・あらゆる領域に広がる    ⇒バリエーションも多いし,ソフトウェアサイズも様々である.  ・「車載ソフトウェアの課題は何なのか?」と聞かれると,   開発している領域がどこかによって,回答はばらばらになることが多い. ○車載ソフトウェアの現状と課題のまとめ  ・特に車載ネットワークや高機能化の分野が複雑になってきている.    ⇒そのため,AUTOSARが発足.    ⇒元々は,ヨーロッパで同様の危機感があり,そこから作られた団体.    ⇒様々な企業が参加. ○Autosarのコンセプト  ・複雑化された構成をどうすればよいのか,の問いの解として,   自動車メーカサプライヤを超えたソフトウェア流通,再利用の実現を狙うという   ことがコンセプト  ・複数のECUから構成される車両システムを一つの仮想的なECUとして開発,管理を行う  ・Autosar仕様は公式サイトから入手することができる M氏:ダウンロードしたものを調べてみると,リリースのバージョンが様々ありますが,   これはどういうことなのでしょうか. S氏:現在、リリースされているものは2.x系と3.x系がある.4.xは現在開発中.    2.1は比較的ステーブルなものです.   3.0 3.1は機能安全などが含まれています. ○課題に対する取り組みと今後の技術動向のまとめ  ・課題の対する取り組み.    ⇒AUTOSARの現状:複雑さをいかに低減させるか,如何にソフトウェアを     再利用するかが焦点  ・VFBの仕組みが実現.  ・ECUソフトウェア全体構造や部品企画. <ADLについて> S氏:続いてADLについて説明していきます. ○ADL  ・Architecture Design Languageの略.  ・ADLとは製品要求を設計に具体化していく概念で,設計に焦点を当てた   システム技術言語.  ・ADLを用いることによって,AUTOSARで不足する要件から設計を補完できる.  ・ハードウェアモデルに用いることができる. ○ADL導入のモチベーション  ・現状よくある問題への対応.    ⇒過去のレビューで検討しているはずだが,今回の変更の影響が不安.    ⇒差分開発した結合検査項目の網羅度が不安.  ・正確に仕様を記述する.    ⇒誤解されがちであるが,正確に書くことは,詳細に書くこととは異なる.    ⇒正確に書くことは,必要なところだけを正確に記述することである. ○EAST-ADL2  ・車両のモデリング開発に特化したADL    ⇒カレントバージョンは2.0  ・特徴は以下の通り    ⇒AUTOSARとの連携が言語使用レベルで考慮できる    ⇒差分開発への対応    ⇒V&V(テスト対策)への対応  ・設計意図を残すことも意識している. Y氏:V&V(バリデーションとベリフィケーション)は,    何をしなければいけないのかを皆で共有することを目標としています.    みんなで議論するため,という位置づけがあります. M氏:バリデーションとベリフィケーションは別ですか? Y氏:みなさんが設計で行っているものは大抵ベリフィケーションとなります.    仕様書を製品にきちんと落とし込むことをベリフィケーションといいます.   商品企画ならバリデーションになることが多いです.   顧客が何をほしがっているのかを探るようなことはバリデーションに分類されます. ○まとめ  ・車載ソフトウェア開発の現状と課題    ⇒大規模複雑化するソフトウェアを以下に効率よく開発保守を行うか  ・課題に対する取り組み    ⇒複雑さの提言とソフトウェア流通再利用の実現に向けて,AUTOSARを中心と     した要素技術開発が活性化 <ディスカッション> S氏:ツールベンダーの方から見ると,トレースアビリティが大事であるとのことで,   これに対して有効なツールを検討しているということもあります.   優秀な設計者ならトレースアビリティについては詳細に書かなくてもわかりますが,   ソフトが大規模化したからとか,新しく入って来る者を考えると,書かざるを   得ないです.   トレースアビリティは師弟関係で教えてきたところがあったか,形式的に残す   必要が出てきています.   これらについてどう教育しているのか知りたいですね. M氏:新人の教育で言うと,まずはテストについていくつか教えているだけですね.   品質に苦労しながら,力づくでやっている状況に見えます.   そろそろ方法を改良していく必要があると思います.   大事なところ,核のようなものをピンポイントで教育できれば良いのですが   なかなか難しいのが現状のようです. S氏:失敗から勉強することはいくらかあります.   最近の人事は,失敗すると減点めいたことをしますが,   振り返り的なことを行うことが必要かと思います.   そして失敗を恐れてはいけないことも大事ですね. M氏:品質問題を起こしたときに若手技術者は伸びると思います.   品質とデッドラインが相当厳しい中で皆仕事を行ってます.   その中で得られるものは多いと思います. S氏:学生には,SSESTやETロボコンなどに挑戦し,全力で取り組んでもらって,   そこで思いっきり失敗し,いくらか学んでほしいと思いますね. M氏:失敗を考えて,若手技術者にはまずテストからやってもらっています.    要求分析をミスすると品質は大きく左右されてしまうが,    テストで一発ミスを起こしても相当な品質低下は考えにくいですね. S氏:要求が崩れるのは一番の問題.    分析の際,要求を網羅的に出すにはどうすれば良いのかが現状の課題です.    特に設計の際の制約に関してはよく忘れ去られているように思えます.    この部分の教育は非常に難しいですね.    E氏が記事で回路設計をされていましたが,コスト制約からハードの設計を一度   プロトタイピングして,    実際には必要のないところを外されていました. M氏:今回,E氏はパターンを用意されていました.    このパターンを事前に用意していたのは何故なのでしょうか.    また,このような勘のようなものを新入社員に教えるにはどうすればよいの   でしょうか. E氏:結論から言うと,なぜパターンを起こしたのかというと,納期までの時間が   なかったため.    大手の企業では社員にソースを書かせることは減ってきています.    設計に慣れているものと新入社員では仕様書の出来具合はぜんぜん違います.    企業であるから,失敗して学ぶ機会を多く用意することも難しいが,    どこかで社員を育てる実験牧場みたいなものがほしいと思います. S氏:ソフトウェアでは排他制御の設計があります.この排他制御には問題も多い.    排他制御はできれば少なくするが,どこまで減らせるかといったノウハウや   嗅覚をどうやって引き継げるのでしょうか.    設計意図などの引き継ぎはどのように行うのが有効なのでしょうか. Y氏:他人に伝えるための設計意図は書いてくれない,というより伝えられません.    設計意図は書くべきですが,絶対にこれでは伝えられないから,聞きにいかな   ければなりません. M氏:こちらも聞くと教えてくれるのですが,向こうではないと絶対にわからないこと   があります.    良い設計者がいれば,そこの近くにいる設計者は自然と上達するとは思います.    人数的に無理があるなら,仕方ないが勝手に分類するしかないかもしれません. S氏:設計するときの前提条件を明確にして書くことの大切さをインタフェースの記事   に書きたかったんですけどね. T氏:フレッシャーズ向けではない方が良いかもしれませんね. M氏:フレッシャーズということで,若手に言いたいこととしては,    わからないところは絶対に聞かないといけない,ということですね.    もちろん,全てを聞くような人材も良くないです.    コミュニケーション能力向上もあるが,特にポイントを絞った質問はいくらか   すべきだと思います. S氏:聞くポイントがわからない人材もいますが,最初は仕方ないかもしれません.    要求のポイントだけでも,設計者に聞くことでかなりの違いがあると思います.    Yさん,他に言いたいことはありますか. Y氏:設計書が綺麗でも,できたものがダメなものはダメということも押さえる必要は   あると思います.    これらは良いものをつくる,という前提で,さらに良いものを作りたいという   ところで,正確に記述する能力をつけたいですね. S氏:設計に関して会社としての強みは,多人数でSW/HWで絶えず良いものを出せる   ことですね.    また,多人数でレビューするところで要求の漏れがないかどうかを見るかが   重要だと思います.    このようなレビューは形式的でなくてはならないと思います. T氏:担当編集者として最後にコメントさせてください.    連載のタイトルと内容がかけ離れたことがあったのは申し訳ないと思っています.    なかなか興味を持ってもらえるような分野とは言えないかもしれませんが,    そのような事柄も連載にどんどん取り入れたいなと思っています. B氏:SSEST実行委員会としてコメントします.    最初はフレッシャーズ向けということで連載を開始しました.    途中から方針変更して,このような形に落ち着きました.    ライントレースカーキットを作っていただいたが,これと連載記事とうまく   絡められたらよりよかったと思います. S氏:この後のセッションでは連載企画で取り上げたライントレースカーキットを    組み立てるセッションがあるので,そちらも良かったらどうぞ. M氏:大判振る舞いで今回に限って部品が無料でついてきます.みなさんInterfaceの   5月号を買いましょう! S氏:時間になりましたのでこれで終わらせていただきます.ありがとうございました. ■まとめ 要求分析は製品開発の際に非常に重要であるが,要求を網羅的に洗い出すことは難しい のが現状である. 特に,他人に伝えるための設計意図はなかなか上手く伝えられるように表現することは 難しい. モデリング言語を用いて正確に記述することがあるが,出来上がった製品がダメで あれば意味は無く, 良い製品を開発するという前提で分析を正確に行う必要がある. また,若手技術者を育成させるためには,若手技術者自身が失敗を経験することも 必要であり, 熟練技術者の近くで設計を行ったり質問をするなどすればノウハウを伝えることは 可能であると考えられる. これらの話題が連載記事に載せられなかったが,今回のセッションでは以上の話題を 討論することが出来た. 以上.