**********************************************************************
セッション s3-a
テーマ：名古屋大学組込みシステム研究センターのAUTOSARに対する取り組み
日時：8/23 10:30-11:50
講師：鴫原 一人 (名古屋大学)
参加人数：50人程度
**********************************************************************

10:30 開始

AUTOSARの概要とNCESで行っている取組みについて紹介

---------------
AUTOSARの概要
---------------
AUTOSARとは：車載向けプラットフォームの仕様
　−近年の自動車開発のコストは半分近くがソフトウェア関連
　−各社独立してソフトウェアを作るのは無駄が多い、再利用できない
AUTOSARのコンセプト
　−メーカーやハードウェアに依存していた規格を標準化
　−アプリケーションがハードウェアに依存しないように→再利用性向上

ソフトウェアコンポーネント(SW-C)とRunTime Environment(RTE)
 BSW：RTEからの要求に対してマイコンを制御するまでの処理を階層構造に
     よって抽象化するためのコンポーネント群
  →部品メーカー、ツールメーカーが提供
 マイコンを抽象化する層：半導体メーカーがマイコンと合わせて販売
 OSのターゲット依存部(インターフェースが未規定)

スライド表示：AUTOSARロードマップの紹介(最新版はR4.1.1)
　−NCESではR4.0.3版に準拠して開発実施

AUTOSAR導入のメリット・デメリットとそれに対する見解
 メリット
　 −「開発プロセスの全領域が専用ツールによってサポート」
　　 →疑問：「全領域」とは？
　 −自動車メーカーとサプライヤーとのやり取りがXMLベースの
     標準フォーマットで統一
　　 →指摘：AUTOSARで定義されているXML仕様では不十分
 デメリット
　 −開発効率が上がる代わりにリソースも増加
　　→指摘：車載システムとしては致命的では


----------------
NCESの取り組み
----------------
NCES：名古屋大学大学院情報科学研究科附属組込みシステム研究センター
NCESの目的：産学連携による研究・組込みシステムのための人材教育
AUTOSARに関する研究は大きく分けて2つ
 ①AUTOSARの仕様評価(2008〜2010年)
 ②実用可能なAUTOSAR OSの開発(2011年度〜現在)
　 ①当時のAUTOSARはマルチコア非対応→マルチコア化して検証
　 →成果：TOPPERS/ATK2を開発、オープンソースとして公開
 複数の企業と共同で開発を行うコンソーシアム型共同研究
 　−企業からは何名かが名大に常駐

スライド表示：3年計画のロードマップ(2011〜2013年度)
　−2013年：OS開発：トレーサビリティ，MC/DC解析
　　　　　　COMスタック，RTEも開発


------------
AUTOSAR OS
------------
スケーラビリティクラス(SC)：OSが提供する機能に応じてSCが定義されている
OSには4つのSC(SC1〜SC4)が存在
　SC1：OSEKの上位互換(基本セット)
　SC2：SC1＋タイミング保護
　SC3：SC1＋メモリ保護
　SC4：全部
SC1とSC3を対象にマルチコア拡張

OSEKに対応したOSはTOPPERS/ATK1

OSEKとAUTOSARの関係
　AUTOSARはOSEKの上位互換
　しかし「AUTOSAR化＝ソフトウェアコンポーネント化」→直接OSを使うわけではない
　　→OSEKで作ったアプリケーションをそのままAUTOSARで使えるわけではない

OSEK/VDX仕様との主な差分
　スケーラビリティクラスの導入：タイミング保護、メモリ保護の導入
　コンフィギュレーション方法がXMLに
　マルチコア対応(AUTOSAR4.0シリーズ以降)

AUTOSAR OS仕様の問題点
　OSEK/VDXとの差分しか記載されていない
　曖昧な仕様や検討不足であることが多い
　英語で記述されているものは日本での普及が遅い
　　→次世代車載システム向けOS仕様の日本語化を行う

トレーサビリティを見据えた仕様タグ
　要求事項であるにもかかわらずタグが振っていない場合が多い
　曖昧な基準のタグも選別
　　→仕様タグの追加、整理

スライド表示：仕様タグの件数、追加した仕様の内訳
　AUTOSAR原文のタグ数：約620
　NCESで追加したタグ数：803
　　→これだけ厳密に規定しないとOSは作れない
　　→原文のままではAUTOSAR仕様の品質は良いとは言えない

OSEK/VDX仕様との矛盾の例
　OSEKでは拡張エラーと規定されているものがAUTOSARでは標準エラーと規定
　　→AUTOSARの誤記と判断

NCES仕様に改変したAUTOSAR仕様
　戻り値のデータ型がStatusTypeでないシステムサービス

NCES独自仕様
　曖昧な仕様：SC1でのプロテクションフックの扱い
　　−SC1でCPU例外が起きたら？→SC1でもプロテクションフックを呼び出す
      ように規定
　未定義の仕様：OSが管理するスタック設定

OSアプリケーション(OSAP)とは
　アプリケーションごとに分割した複数のOSオブジェクトの集合
　OSAPに対して提供する機能：OSAPの終了処理(再起動も可能)、信頼関数
  (非信頼OSAPからアクセス可能となる)

メモリ保護機能の問題点
　リソース獲得中のOSAP強制終了(R4.0.2)
　　−ほかのOSAPに含まれるリソースを取得していた場合そのOSAPが強制終了
      されるとリソースはどうなるのか？
　　　→R4.0.3で解決された
　非信頼OSAPのISR
　　−非信頼OSAPに所属するISRを実現する場合、割込み発生後、MPUを非特権モードに
      切り替えてメモリ保護属性を設定する必要がある
　非信頼ISRからシステムサービスを呼び出す場合、ソフトウェア割込み等で対応する必要がある
　信頼関数、信頼ISAOの終了
　　−信頼関数実行中に終了してよいか？

機能レベルの導入
　メモリ保護の機能レベル　ATK2では機能レベル2を採用

スピンロック
　マルチコアにおいて、異なるコアのタスク・ISR間の排他制御に用いるOSオブジェクト
　AUTOSAR仕様ではスピンロック獲得中に割込み禁止としない
　　→スピンロックの問題点
　　獲得順序エラーは同じタスク/ISRに対してのみ有効であるので、特定のシーケンスで発生する
    デッドロックは防止できない
　NCESでは独自に割込み禁止使用を規定
　　→AUTOSAR R4.1.1で同様に割込み禁止の仕様追加


-------------------
TOPPERS/ATK2の紹介
-------------------
ATK2について：SC1、SC3(機能レベル2)を2013年1月に公開
FPGAで検証

OSのコンフィギュレーション方法
　ATK2では2つの方法をサポート
　・ディスクリプションファイル(XML、AUTOSAR仕様)
　・静的API(μITRON仕様)
　テストスイートによるATK2の検証
　テスト項目数が20万件と膨大であるため、組み合わせテストツールでテストケースを自動生成
　検査対象OSをμITRON仕様からAUTOSAR仕様に変更

ATK2設計書およびAKTSPの取り扱い
　外部仕様書・ソースコードのみオープンソース、それ以外は有償で提供

Elektrobit社製 tresos AutoCore上での動作確認：tresos上のOSをATK2に変更して動作確認


-------------
COMスタック
-------------
同じECU内での通信：RTE
異なるECUの通信：CANなど→スタック構造になっているコンポーネントがCOMスタック

開発範囲
　プロトコルをCANに絞る
　ボディ系ドメインで使用されるであろう機能に絞ったサブセットを対象とする

開発方法
　参加企業からのコントリビュート(R3.0.2)
　　→R4.0.3への変更点のみ修正
　コンフォーマンステスト(R4.0.2)を使用したテストドリブン開発

マルチコア仕様
　R4.0.3：マスタコアでしかCOMによる通信ができない
　　→スレイブコアから通信する場合は一度マスタコアを経由する必要がある
　R4.1.1：マスタ・サテライト通信をサポート
　　→NCESで過去に同様の研究実績がある

RTE
　SW-C側に向けてAPIを提供する開発環境
　コンフィギュレーション情報に従って…
　　・SW-CやBSWの実行スケジューリングを制御
　　・効率的なSW-C間の通信を実現
　　・RTEジェネレータから必要APIが生成される

設計
　ECUごとに設定情報を貰うことになっているが実際は複雑
　SW-Cの中でRunnable(位置関数にマッピングされる)がどのタスクで動くかはわからない
　　→あくまでSW-Cに関する情報のみでタスクに関する情報は持っていない
　　→ECUコンフィギュレーションをやろうという時に詳細情報をECUごとに設計する必要がある
　　→ECUインテグレータがXMLファイルを元にそれぞれBSW用ディスクリプションファイルを作る

RTEジェネレータがAPIを自動生成→ラッパー関数を生成
　ここで生成したOS用ディスクリプションはOSジェネレータ(コンフィギュレータ)、COM用は
  COMジェネレータで処理

RTEの開発：参加企業に委託
マルチコアを使う機能はRTEに入れる


------------
質疑応答
------------
Q. 「AUTOSARの仕様が悪い」とあったが、感じ方はそれまでの経緯・経験次第では
A. 各社の要望を取り込みすぎて複雑になっている、実装する側の観点から見ると，良い仕様とは言えないと思う

Q. 仕様に「穴がある」のは古い規格に対応するためと聞いたが
A. 再利用性を失っても適用可能な範囲を広げるため
　 「AUTOSARに対応する」とは、RTEの上で動かしているSW-Cの再利用性が高まるということ
　　　→直接呼び出した時点でそれはAUTOSAR対応ではない

Q. コンフィギュレーションするときは整合性のチェックを入れているのか
A. チェックしている

Q. 今のAUTOSARでICC3は実装できるのか
A. やっているところもある

Q. どのタスクを割り当てるかは手動か
A. 手動でないと出来ない(スケジューリングはRTEジェネレータが行う、関連付けだけ
   人の手が必要)

Q. モジュールはECUを問わず使えるのか
A. 別のECUに持って行った時に手を加えなくてよいのはSW-Cの中だけ
   スタック通信はオーバーヘッドが無視できない大きさ


11:50終了

------
まとめ
------
AUTOSARの概要と現在の問題点、それに対してNCESが行っている研究についての紹介を行った。
同時にTOPPERS/ATK2からTOPPERSプロジェクトについても言及した。
質疑応答の時間を多くとることができ、有用な議論が出来た。

以上