********************************************************************** s4-a テーマ：車載ソフトウェアプラットフォーム講師: 佐藤洋介（株式会社デンソー）日時：2008/9/05 13:30〜15:00 聴講者：50名程度 ********************************************************************** 社内で車載ソフトウェアプラットフォームを担当している佐藤です。よろしくお願いします。昔は、携帯、カーナビを作っていて今は、車載ソフトウェアプラットフォームの標準化活動等をしてます。デンソーを簡単にご説明致しますと、刈谷市で一番高いビルがあります。会社全体からみた事業の割合で、20％がソフトウェア事業になっています。今回発表する内容なんですけども、車載ソフトウェアの課題はどんなことがあるのか？それを解決していくための取り組みなどを紹介していきたいと思います。あと、マルチコアなども、補足的に説明していきたいと思います。 ○カーエレクトロニクス製品群車載は4つにわかれています。・パワートレイン・シャシ・ボディー・情報通信言いたいことは、この４つのドメインに分かれていることです。この事を覚えていてください。 ○カーエレクトロニクスの歴史メカニカル→エレクトロニクス→デジタル化の流れになっています ○（補足）高機能化の事例 Vehicle Dynamics Integrated Management どんな路面状況であってもドライバの操作をサポートし、高い予防安全性を運動性能実現するシステム。これまでに個々に独立して制御していた、エンジン制御、ブレーキ制御。ステアリング制御を統合することで実現されている。人間の思うように制御してきている。車内LANを使って、一つの目的を達成する。 ○（補足）ネットワーク化の事例 3つの車載LANに分かれます。また、ECUの数が60個になっています。次の車種では、100ぐらいになるのではないかと言われています。車載LANのプロトコルがあるのですが、コストや通信のスピードで使い分けている。 ○車載ソフトウェアの特徴・ハードリアルタイム性・省リソース車載の特徴としては、高い品質要求、納入先との分担開発これによって、車両メーカとサプライヤとの関係が、用途によって異なってくる。あと、頻繁な仕様変更があります。さらに、バリエーションも豊富です。例えば、年間2000本以上もでている。 ○車載ソフトウェアの現状数kのソフトウェアだったり、それぞれで特徴がバラバラです。さっきの４群で、それぞれの特徴・傾向が見えてきます。 ○車載ソフトウェアの現状と課題・車載ソフトウェアの現状　・車載ソフトウェアは大規模・複雑化の傾向　　・環境（制御対象）の複雑化　　・車載LAN構成、車載LANプロトコルの多様化・要求（制御仕様）の複雑化　　・従来のデバイスを制御するといった単機能要求から、　　・完全に独立していた機能を組み合わせることで　　・新しいサービスを提供するといった機能連携要求へ変化している分野一言で問題を言うと、大規模化・複雑化に対してソフトウェアでどうやるか？ ○課題に対する取り組みと今後の技術動向 ○今までの車載ソフトウェア開発・開発単位は、ハードを制御する単機能を実装する小規模なチーム・チーム毎に、ソフト、ハードに精通し、製品のすべてを把握することのできる　スーパーエンジニアが存在　・製品によって全行程を１人で担当　・ソフトウェアは規模も小さく、伝統工芸品に近い・OJT（一子相伝）によるノウハウ伝達 ○課題解決の方向性どのように、取り組むかという戦略がいくつかあるのですが、・戦略(1):ボトムアップ戦略　大規模・複雑化に対して、小規模なチームをボトムアップ的に積み上げる・しかし　・チーム毎に文化が異なるため　　・開発能力は単純にチームの足し算にはならない　　・チーム間でインタフェースの擦り合わせなどのオーバヘッドが発生　・作業の標準化が困難　　・チーム毎に再利用方法、ドキュメントルール、コーディングルールなどがバラバラ　　・バリエーション対応には、マクロ、コンパイルスイッチ、　　　関数ポインタによるコールバック　　　など様々な実装技術があるが、どれを採用するかは各チーム任せ・人件費・管理費が膨大になる今まで、やらなくてよかった会議やミーティングをやるなどオーバヘッドがでてくる。　　そろそろボトムアップ戦略は限界にきているそこで、戦略(2):標準化ですが、これは、アーキテクチャを標準化し、プラットフォーム上にコンポーネント群を組み合わせ開発する。極力開発せず、資産や市販のコンポーネントを組み合わせる開発スタイルへ移行したい。 ○課題に対する取り組み・AUTOSAR(Automotive Open System Architecture) ・自動車メーカとサプライヤが中心になり、　車載ソフトウェアや電子アーキテクチャの共通化を目指して設立したコンソーシアム・活動のねらい　1:自動車メーカ、サプライヤを超えたソフトウェア流通、再利用の実現　2:車載システムの複雑さの低減　　LANの構成が複雑になってきている ○AUTOSARパートナーシップ構成コアパートナーは、仕様の決定権基本は、ヨーロッパを中心とした車載やサプライヤがいてそこにぽつんとTOYOTAがいる。プレミアムメンバは、仕様の提案権をもっている。 ○AUTOSARコンセプト・VFB(Virtual Functional Bus) ・ハードウェアやネットワークリソースを仮想化したバス　　複数のサプライヤが開発したコンポーネントをVFB上で組み合わせ開発する　→1:自動車メーカ、サプライヤを超えたソフトウェア流通、再利用の実現・複数のECUから構成される車両システムを一つの仮想的なECUとして開発・管理する　→2:車載システムの複雑さの低減 RTE(Run time environment)はCORBAで言うところのスタブ・スケルトンにあたります。 ○AUTOSAR開発プロセス・Contract Phase ・Generation Phase ・Integration Phase ○課題に対する取り組みと今後の技術動向（まとめ1）・課題に対する取り組み　・複雑さの低減とソフトウェア流通、再利用の実現に向けて、　　AUTOSARを中心とした要素技術開発が活発化・今後の技術動向　・製品面：機能安全（ISO26262）対応　　・複雑化する電子技術の品質確保　・電子技術面：マルチコア化　　・設置スペースと消費電力設置スペースが限られているのでマルチコア化しないといけない ○課題に対する取り組みと今後の技術動向（まとめ2）・AUTOSARの現状（要素技術）　・VFBの仕組みが実現　　・ECUソフトウェア全体構造：①アーキテクチャ　　・SW-C部品規格：②DSL ・SW-C開発環境：③ツール・AUTOSARの今後（周辺技術）　・機能安全（ISO26262）対応　　・安全要件管理：④ADL 　　・仕様検証：⑤形式手法　　・SW-C流通時の責任分担：⑥Automotive SPICE ・電子技術面　・マルチコア化 ○AUTOSAR要素技術解説　①AUTOSARアーキテクチャ　②AUTOSAR DSL 　③AUTOSARツール ○①AUTOSARアーキテクチャ Operating System: OSEKをベースとした、AUTOSAROS Services: ECUを管理するためのモジュール Communication: 他のECUと通信するためのモジュール ECU Abstraction: ECUハードウェアをSW-Cがアクセスしやすいように抽象化したモジュール Microcontroller Abstraction: ECUハードウェアに対しアクセスするためのドライバ Complex Device Drivers: ECUハードウェアに直接アクセスするためのモジュール ○②AUTOSAR DSL VFB上にSW-Cを流通、再利用するための部品規格。コンポーネントはポートを複数持つことができます。ポートの種類は2種類あります。 ○（補足）VFB上のSW-C間通信プロトコル車載では、SenderReceiver・ClientServer通信しかありません。 ClientServer通信は関数コールですね Q：送りっぱなしなのか？ A:ackが返ってくる設定もすることができますが、基本は投げ放しですね。ですが、故障診断などでにはackを使ってます。 ○③AUTOSARツール Contract Phase 先行開発するためにヘッダだけを出力することができる ○（補足）AUTOSAR仕様の入手先 http://www.autosar.org 仕様はすべてフリーになっています。ただし仕様は膨大になっています。 ○AUTOSAR周辺技術解説 ④ADL ⑤形式手法 ⑥Automotive SPICE ○④ADL ADL（Architecture Description Language）とは　・製品要求を設計に具体化していく概念設計にフォーカスしたシステム言語　　AADL,EAST-ADL, SysML 　・ADLを使うことによって　　AUTOSARで不足する、要求からSW-Cまでを補完　・AUTOSARで不足する、ハードウェアモデルも管理できる ○SysMLとはちょっと補足説明します。・UML2.0の方言　UML2.0をベースに製品要求から設計に具体化するために必要なダイグラムを追加・拡張　UML2.0で組込みシステムにいらない機能を捨てる・UMLベースのため、AUTOSAR UML Profileと親和性が高い・SysMLの特徴　・各部品にまたがる関係だけを記述　　・領域固有のダイアグラムを置き換えるものではない　・システム評価に必要な特性のみを記述　　・領域固有のダイアグラムと同等の記述力はない　・SysMLでできること　　・設計変更時の影響分析が容易に行える　　・ハードウェア（機械系、電気系）とソフトウェアという異なる領域を跨って　　　影響分析ができる。　　　機能安全対応では必須となる ○⑤形式手法・形式手法導入のモチベーション　・機能安全で求められている　・せっかく苦労してVFB上でSW-Cをモデル化するのだから、手間をかけた分、　　自動的に検証したい・形式手法の分類　・Semi-formal method 　　・厳密な数理的裏付けはない（ビジュアル系）　　　・Howを記述　　・表現力、 ○LTSA 状態遷移モデルが論理式を満たすことを網羅的に検査する ○⑥AutomotiveSPICE ・誕生の背景　・相次ぐ電子システムの不具合の欧州自動車メーカは苦しむ　　・自動車メーカとサプライヤの責任のなすりつけ合いに発展・モチベーション　・自動車メーカとサプライヤとの責任分担をルールとしてはっきりさせ　　サプライヤの品質保証システムを自動車メーカが監視したい・AUTOSARとの関係　・AUTOSARのねらいは「自動車メーカ、サプライヤを超えたソフトウェア流通、　　再利用の実現するため、責任分担の明確化は必須 ○AutomotiveSPICEとCMMIとの違い CMMIとの違いは・源流が違う　・CMMI:SEI系　・AutomotiveSPICE:ISO/IEC 12207系・視点が違う　・CMMI:開発組織の成熟度　・AutomotiveSPICE:自動車メーカ・サプライヤとの契約・対象が違う　・CMMI:ソフトウェア　・AutomotiveSPICE:車載電子システムとソフトウェア ○まとめ・車載ソフトウェア開発の現状と課題　・大規模化・複雑化するソフトウェアをいかに効率よく、　　開発・保守を行うか？・課題に対する取り組み　・複雑さの低減とソフトウェア流通、再利用の実現に向けて、　　AUTOSARを中心とした要素技術開発が活発化・今後の技術動向　・製品面：機能安全(ISO26262)対応　・電子技術面：マルチコア化・AUTOSARの現状　・VFBの仕組みが実現：アーキテクチャ/DSL/ツール・AUTOSARの今後　・機能安全対応：ADL/形式手法/Automotive SPICE 　・電子技術面：マルチコア化 ■質疑応答 Q1:AUTOSARのコンセプトとしてVFBをしようして　ハードとソフトを切り分けて考えるっていたじゃないですか、　そうすると現状の車メーカは、ハードとソフトを大体ひとまとめで、　サプライヤが提供すると思うのですが、AUTOSARの利用を考えると　今後はソフト単体でもサプライヤが提供することも考えられるのでしょか？ A1:そうですね。　今後はソフト単体での販売も考えられますね。 Q2:率直に言ってAUTOSARは使い物になるのか？ A2:もちろん。 Q3:部分的には使えると思うんですが、　どうなんですかね？ A3:まずは、直接事故に関係しないボデー系で実績を積んでから、　その他のドメインに展開していく流れになっていますね。　情報通信の方は、今年から発足したばかりなので、　しばらく時間がかかるでしょうね。 Q4:走る・曲がる・止まるに入ってくるのか？ A4:入ってくると思います。　それはなぜかというと、FlexrayがAUTOSARに依存している部分が多いので　必然と入ってくることになるでしょう。