名古屋学組込みシステム研究センター (NCES) の AUTOSAR に対する取り組み 2013 年 8 23 ( ) 名古屋学鴫原 1

Size: px

Start display at page:

Download "名古屋学組込みシステム研究センター (NCES) の AUTOSAR に対する取り組み 2013 年 8 23 ( ) 名古屋学鴫原 1"

こうざぶろうかやぬま
5 years ago
Views:

1 名古屋学組込みシステム研究センター (NCES) の AUTOSAR に対する取り組み 2013 年 8 23 ( ) 名古屋学鴫原 1

2 次 1. AUTOSARとは 2. NCESの取り組み 3. AUTOSAR OS 4. TOPPERS/ATK2の紹介 5. COMスタック 6. RTE 7. まとめ 2

3 載ソフトウェアの課題と再利性の向上動の製造コストに占める電部品の割合 2007 年 :20 30% 2015 年 :40% ソフトウェアの再利性向上が急務どの OEM へも提供可能としたいサプライヤ開発ソフトウェア OEM A OEM B OEM C 3

4 設 AUTomotive Open System ARchitecture の略称 2003 年に設 Core Partner Premium Members:34 社 Associate Members:72 社 BMW Group BOSCH Continental DAIMLER Ford GM PSA Peugeot Citroen TOYOTA VOLKSWAGEN 2013 年 5 現在 4

5 AUTOSAR のコンセプト従来アプリケーションハードウェア AUTOSAR アプリケーション標準化インタフェース AUTOSAR HW 依存インタフェースハードウェア "Cooperate on standards, compete on implementation" メーカーやハードウェアに依存するインタフェース, コンフィギュレーションを標準化ソフトウェアの再利性が向上し, 開発コストの低減も実現される 5

6 アーキテクチャ Application Layer SW-C SW-C SW-C SW-C Runtime Environment (RTE) BSW(Basic Software) System Services Memory Services Communication Services I/O Hardware Abstraction Complex Drivers OS Onboard Device Abstraction Memory Hardware Abstraction Communication Hardware Abstraction Microcontroller Drivers Memory Drivers COM Drivers IO Drivers Microcontroller 6

7 SW-C と RTE エンジン制御やセンサ監視など, アプリケーション毎にソフトウェアコンポーネント (SW-C) の開発をう SW-C からは RTE から提供される API を使して, 他の SW-C との通信処理や排他制御をう RTE より下位層は,SW-C からはえないよう抽象化されるどの ECU で実されるかもえない RTE は SW-C からの要求にしたがって,BSW を使して, ECU を制御し, アプリケーションを効率的に実する SW-C は,ECU に依存せず開発できるので再利性が向上する Application Layer SW-C SW-C SW-C SW-C Runtime Environment (RTE) 7

8 BSW RTE からの要求に対して, マイコンを制御するまでの処理を階層構造によって抽象化するためのコンポーネント群ほとんどの BSW は OS 上で動作するため,SW-C,RTE も最終的には OS 上で動作するサービス層 RTE ECU 抽象化層 BSW(Basic Software) System Services Memory Services Communication Services I/O Hardware Abstraction Complex Drivers OS マイコン抽象化層 Onboard Device Abstraction Memory Hardware Abstraction Communication Hardware Abstraction Microcontroller Drivers Memory Drivers COM Drivers IO Drivers Microcontroller 8

9 想定される開発対象者 SW-C SW-C Application Layer SW-C SW-C 動メーカ部品メーカ Runtime Environment (RTE) BSW(Basic Software) System Services Memory Services Communication Services I/O Hardware Abstraction Complex Drivers 部品メーカツールベンダ OS Onboard Device Abstraction Memory Hardware Abstraction Communication Hardware Abstraction Microcontroller Drivers Memory Drivers COM Drivers Microcontroller IO Drivers 半導体メーカ OS のターゲット依存部は? ( インターフェイスが未規定 ) 標準化により部品化が可能となり再利性が向上する 9

10 ロードマップ NCES では R4.0.3 に準拠して開発を実施 2013 年 4 9 にリリースされた <5th AUTOSAR Open Conference> 10

11 AUTOSAR 導のメリットデメリット全領域とは? AUTOSAR で規定されている XML 仕様は分でない載ソフトウェアでは致命的な問題 <MONOist 11

12 次 1. AUTOSARとは 2. NCESの取り組み 3. AUTOSAR OS 4. TOPPERS/ATK2の紹介 5. COMスタック 6. RTE 7. まとめ 12

13 名古屋学組込みシステム研究センター (NCES) 設的組込みシステム分野の技術と材に対する産業界からの要求にこたえるために, 組込みシステム技術に関する研究教育の拠点を, 名古屋学に形成産業界が必要とする技術課題を分析抽出し, 学における基礎研究に反映活動領域 ( スコープ ) 組込みシステムに関する以下の活動に, 産学連携の枠組みで取り組む学の持つ技術シーズを実現 / 実化することを指向した研究 ( 第種基礎研究 ) プロトタイプとなるソフトウェアの開発組込みシステム技術者の教育 / 材育成 13

14 1AUTOSAR OS 仕様の実装 / 評価プロジェクト概要 (2008 年度 2010 年度 ) Release 4.0の仕様の明確化と修正 NCES 独のマルチコア拡張必要性とオーバヘッドのトレードオフを考慮するため, 機能レベル ( 後述 ) を定義プロトタイプ OS を実装し, 仕様の妥当性を評価成果物外部仕様書これらの成果を活かしてオープンソースで提供したい OSEK/VDX 仕様を統合した1つのドキュメント全仕様を本語で記載 OSソースコード (SC1,SC2,SC3,SC1-MC,SC3-MC) 未実装の機能あり AUTOSAR 仕様の曖昧な点に対する分な検討は未実施単体評価スイート ( 機能評価, 性能評価 ) 分な検証は未実施 14

15 2 実可能な AUTOSAR OS の開発プロジェクト概要 (2011 年度現在 ) 既存の外部仕様書,OSソースコードをベースとする AUTOSAR 普及に伴い, 国産のAUTOSAR OSの開発を指す TOPPERSプロジェクトからオープンソースとしてリリース ATK2: AuTomotive Kernel version 2 ATK1はOSEK/VDX 仕様 ( オープンソース ) 外部仕様書も, さらに検討, 精査をい公開するテストスイートも合わせて開発 ( 公開はしない ) 段階的にCOMスタック,RTEも開発していくコンソーシアム型共同研究として実施 15

16 コンソーシアム型研究組織とは名古屋学組込みシステム研究センターが設定した研究テーマに対して, 複数の企業団体が参加し共同で研究開発をう教員 / 研究者企業の経験 / 知コンソーシアム型研究組織材育成ビジネス発展研究者 / 技術者 ( 共同研究員 ) 産学官連携による技術課題の解決名古屋学組込みシステム研究センター (NCES) 参加企業 16

17 参加企業と数 (2013 年 5 時点 ) ( 株 ) ヴィッツ企業名常駐 1 研究協 5 ( 株 ) 永和システムマネジメント ( 株 )OTSL ( 株 ) サニー技研 ( 株 ) デンソー ( 株 ) 東芝トヨタ動 ( 株 ) ( 株 ) 豊動織機パナソニックアドバンストテクノロジー ( 株 ) 富ソフト ( 株 ) ルネサスエレクトロニクス ( 株 ) 合計上記の他, 名教員研究員が 3 4 名実作業に参加 17

18 ロードマップ機能拡張 2011 年度 2012 年度 2013 年度 OS 開発テストスイートも併せて開発 SC1 SC3 仕様検討 SC3 SC1-MC SC3-MC トレーサビリティ MC/DC 解析評価 COM スタック開発 RTE 開発 Com,CanIf RTE 評価評価 18

19 次 1. AUTOSARとは 2. NCESの取り組み 3. AUTOSAR OS 4. TOPPERS/ATK2の紹介 5. COMスタック 6. RTE 7. まとめ 19

20 スケーラビリティクラス OSが提供する機能に応じてスケーラビリティクラス (SC) が定義されている 4つのSCが存在する SC1 TOPPERS/ATK2-SC1として公開基本機能セット OSEK/VDX 仕様の上位互換 SC2 SC1+タイミング保護機能 SC3 TOPPERS/ATK2-SC3として公開 SC1+ メモリ保護機能 SC4 SC1+タイミング保護機能 +メモリ保護機能すべてのSCをマルチコアへ拡張可能現在,SC1-MC,SC3-MCを開発中 2013 年 6 末に公開予定 20

21 OSEK/VDX OS 仕様載システム向けOSの国際標準 (ISO17356) OS 以外にも, 通信ソフトウェア (OSEK/COM) の仕様なども策定コンフィギュレーションはOILという独記法を使する TOPPERS/ATK1はOSEK/VDX Version2.2.1に準拠しているサポートする機能タスク管理アプリケーションモード割込みイベントアラームメッセージフックルーチン OIL の記述例 ( タスク ) TASK { PRIORITY = 1; SCHEDULE = FULL; ACTIVATION = 4; AUTOSTART = TRUE { APPMODE = App1; APPMODE = App3; }; RESOURCE = Res1; EVENT = Evt1; } 21

22 AUTOSAR と OSEK/VDX OSEK/VDX 仕様 OSEK/VDX 準拠で開発 Version2.2.3 上位互換とする差分仕様のみ記載できる限り再利したい AUTOSAR 準拠で開発 AUTOSAR OS 仕様実際は SW-C では? 22

23 OSEK/VDX 仕様との主な差分スケーラビリティクラスの導タイミング保護, メモリ保護の導カウンタを OS オブジェクトとして定義スケジュールテーブル OS アプリケーション ( メモリ保護のパーティション単位 ) プロテクションフック ( 保護違反時処理 ) スタックモニタリングコンフィギュレーション法の変更 (XML) IOC(Inter OS-Application Communicator) マルチコアのサポートコアを跨いだシステムサービス呼出しスピンロック 23

24 AUTOSAR OS 仕様の問題点 OSEK/VDX との差分しか記載されていない仕様に追加や修正をうと, 差分の差分を管理する必要がある OSEK/VDX 仕様との盾 / 不整合が存在する OSEK/VDX 仕様には仕様タグが無い曖昧な仕様や検討不である仕様が多い英語で記述されている本ではまだ抵抗がある曖昧な英も少なくない仕様タグの付与基準が曖昧要求事項であるのに, 仕様タグが付与されていないことがある複数の要求事項を1つの仕様タグでまとめていることがある 24

25 次世代載システム向け RTOS 外部仕様書の作成 OSEK/VDX 仕様 AUTOSAR OS 仕様外部仕様書本語化 OSEK/VDX 仕様に加え, AUTOSAR OS 仕様で追加 / 修正された仕様をマージトレーサビリティを据えて仕様にタグを付与未定義, 曖昧な仕様に対しては NCES 独仕様を追加 OS の実装に依存した仕様も記載 25

26 トレーサビリティを据えた仕様タグ仕様タグ凡例 COSxxxx :OSEK 仕様 ( 独にタグを付番 ) OSxxx :AUTOSAR 仕様 ( 原に付与されているタグ ) OSaxxx :AUTOSAR 仕様 ( 仕様タグが付与されていない ) NOSxxxx :NCES 独仕様 IOSxxx : 実装依存仕様 DOSxxx : 設計仕様仕様タグは仕様タグの参照と定義次世代載システム向け RTOS 外部仕様書 COS123 テストデータテスト対象仕様タグ - COSxxx -OSxxx 外部仕様書のどの仕様を基に設計実装したかを管理可能どの仕様に対するテストデータかを管理 ATK2 設計書 DOS789 COS123 OS ソースコード /* DOS789 */ 26

27 仕様タグの件数外部仕様書 (514 ページ ) 仕様種別件数 COS 427 OS 620 OSa 177 NOS 803 IOS 223 合計 2,264 (2013 年 6 末公開版 ) 外部仕様書の 2,264 件の内,NOS と IOS を合わせて 1,026 件 OSEK,AUTOSAR に, 数多くある曖昧な仕様や実装依存となっている仕様を明確に規定した 27

28 追加した仕様の内訳種別件数 NOS 803 件曖昧, 未規定のために追加した仕様 364 オーバーヘッドのために追加 / 改変した仕様 219 品質を向上するために追加した仕様 220 AUTOSAR 仕様の品質は良いとはえない 28

29 OSEK/VDX 仕様との盾の例 OSEK 仕様 OSEK では,E_OS_VALUE は拡張エラーと規定されている AUTOSAR では, 標準エラーと規定されている標準エラーはデバッグ済みのアプリケーションでも起こりうるエラーを対象としているため,AUTOSAR の誤記と判断 AUTOSAR 仕様 29

30 NCES 仕様に改変した AUTOSAR 仕様返り値のデータ型が StatusType でないシステムサービス OSEK 仕様実中のタスク ID を取得する StatusType GetTaskID(TaskRefType TaskID); タスク ID を受け取る変数のポインタを引数に渡し, 実結果が戻り値となる AUTOSAR 仕様実中の ISR ID を取得する ISRType GetISRID(void); 実結果が ISR ID となるため, 実状態の ISR が存在しないかエラーが発したか区別不可 ( しかもエラーフックは呼ばれない ) 返り値が無効値となる場合など, エラーフックが呼び出されるべき状況があるため, 返り値の型が StatusType でないシステムサービスでも, エラーフックが呼び出される場合があることを規定 30

31 NCES 独仕様曖昧な仕様 SC1 でのプロテクションフックの扱い SC1 で CPU 例外が発したらどうなる? SC1 でも CPU 例外やスタックオーバーフローが発した際にはプロテクションフックを呼び出すように規定未定義である仕様 OS が管理するスタック設定 OSEK,AUTOSAR 共に, スタック設定に関する記述がない OS で管理するスタックの種類と, スタックのコンフィギュレーションについて規定 31

32 OS アプリケーション (OSAP) とはアプリケーション毎に分割した複数の OS オブジェクトの集合信頼 OSAP アクセス禁 ( ) 信頼 OSAP アクセス禁 ( ) 信頼 OSAP タスクタスクタスクアクセス許可アクセス禁 ( ) アクセス許可アクセス許可アクセス許可タスクタスクタスクカウンタアラームデータ領域アクセス権を付与することでアクセス可能となる 32

33 OSAP に対して提供する機能 OSAP の終了処理信頼 OSAP タスク再起動も可能 OSAP 強制終了終了状態となる信頼 OSAP タスク信頼関数信頼 OSAP 信頼関数信頼関数実信頼 OSAP タスク I/O 領域など信頼 OSAP からアクセス可能となる 33

34 メモリ領域に対する保護と保護違反時の機能保護違反からの復旧処理をユーザが選択可能例 1) プロテクションフック OS シャットダウンも可能タスク (ISR) のみを強制終了信頼 OSAP タスク /ISR 起動アクセス違反発信頼 OSAP データ領域例 2) プロテクションフック OS シャットダウンも可能 OS アプリケーションごと強制終了信頼 OSAP タスク /ISR 起動アクセス違反発信頼 OSAP データ領域 34

35 メモリ保護機能の問題点 1 リソース獲得中のOSAP 強制終了他のOSAPに含まれるリソースを取得していた場合そのOSAPが強制終了されるとリソースはどうなるのか? OSAP 強制終了 TerminateApplication() 信頼 OSAP2 タスク 2 信頼 OSAP リソース獲得中信頼 OSAP1 タスク 1 リソースが強制解除される? 排他制御が崩れる可能性ありタスク1がリソースを解放するまで待つ? タスク2がそれまで待たされる? OSAP 終了処理を低優先度で継続? AUTOSAR R4.0.2 R4.0.3 で解決リソースは OSAP に所属しなくなった 35

36 メモリ保護機能の問題点 2 信頼 OSAP の ISR 信頼 OSAPに所属するISRを実現する場合, 割込み発後,MPUを特権モードに切り換えメモリ保護属性を設定する必要がある信頼 ISRからシステムサービスを呼び出す場合, ソフトウェア割込み等で特権に切り換える必要がある ISRが強制終了される場合に備え, 多重割込み発時は, 元のISRに関する情報を保持しておく必要がある ISRの強制終了を無効にしても,OSAP 全体を強制終了される場合に, 同様の問題が発する割込み優先度 ( 信頼 )ISR1 ( 信頼 )ISR2 t ISR2 が強制終了された場合に ISR1 へ戻るための情報をすべて保持する必要があるオーバーヘッド 36

37 メモリ保護機能の問題点 3 信頼関数, 信頼 OSAPの終了信頼関数実中に終了してよいか? 信頼 OSAPを強制終了する意義はあるか? 信頼 OSAP1 信頼関数信頼関数実中 CallTrustedFunction() 信頼 OSAP タスク I/O 領域など OSAP 強制終了可能 TerminateApplication() データの貫性などが保証できない可能性がある信頼 OSAP2 タスク 2 37

38 機能レベルの導メモリ保護の機能レベル機能レベル 1 信頼 OSAP に所属するタスクをサポート機能レベル 2 信頼 OSAP に所属するフックルーチンをサポート機能レベル 3 信頼 OSAP に所属する ISR をサポート保護違反処理の機能レベル機能レベル 1 保護違反時,OS シャットダウンをサポート機能レベル 2 保護違反時, タスクの強制終了をサポート機能レベル 3 ATK2 では機能レベル 2 を採! 信頼 OSAP の強制終了, 再起動のみサポートする (2013 年 9 末予定 ) 保護違反時, ISR の強制終了,OSAP の強制終了 / 再起動をサポート 38

39 スピンロックとはマルチコアにおいて, 異なるコアのタスク,ISR 間の排他制御にいるOSオブジェクト他のコアで獲得されたスピンロックを獲得しようとした場合, スピンロックが解放されるまでビジーウェイトする AUTOSAR 仕様ではスピンロック獲得中に割込み禁としないデッドロック対策のエラーが 2 つ意されているエラー 1 同じコアのタスク /ISR が獲得しているスピンロックを獲得しようとした場合低優先度 Task1 Task2 Task2 が SPN1 を解放前に TASK1 が起動実中 SPN1 実中スピンロック獲得デッドロック発 SPN1 スピンロック獲得 ( エラーとなる ) エラー 2 コンフィギュレーション時に指定した獲得順序を守らずにスピンロックを獲得しようとした場合 Task1 実中 (Core1) SPN1 SPN2 Task2 獲得順序設定 :SPN1 SPN2 実中 (Core2) SPN2 SPN1 スピンロック獲得 ( エラーとなる ) 39

40 スピンロックの問題点獲得順序設定 :SPN1 SPN2 Task1-1 (Core1) Task1-2 が SPN1 を解放前に TASK1-1 が起動実中デッドロック発 SPN2 低 Task1-2 (Core1) 実中 SPN1 スピンロック獲得 ( エラーとならない ) 優先度 Task2-1 (Core2) Task2-2 が SPN1 を解放前に TASK2-1 が起動実中デッドロック発 SPN1 低 Task2-2 (Core2) 実中 SPN2 スピンロック獲得 ( エラーとならない ) 優先度獲得順序エラーは同じタスク /ISRに対してのみ有効であるので上図のシーケンスで発するデッドロックは防できないスピンロック獲得時は割込み禁とすれば本デッドロックは発しない NCES 独仕様で割込み禁を伴うスピンロック仕様を策定 R4.1.1 で同様のスピンロックが導された 40

41 次 1. AUTOSARとは 2. NCESの取り組み 3. AUTOSAR OS 4. TOPPERS/ATK2の紹介 5. COMスタック 6. RTE 7. まとめ 41

AuTomotive Kernel version2(atk2) ATK2 概要外部仕様書に準拠した OS SC1,SC3( 機能レベル 2) を 2013 年 1 に公開 Nios2 プロセッサのターゲット依存部を同梱 SC1 のみ以下の依存部も同梱 SkyEye(ARM シミュレータ ) V850E2( ルネサスエレクトロニクス

42 AuTomotive Kernel version2(atk2) ATK2 概要外部仕様書に準拠した OS SC1,SC3( 機能レベル 2) を 2013 年 1 に公開 Nios2 プロセッサのターゲット依存部を同梱 SC1 のみ以下の依存部も同梱 SkyEye(ARM シミュレータ ) V850E2( ルネサスエレクトロニクス ) SC1-MC,SC3-MC( 機能レベル 2) を 2013 年 6 に公開予定開発に使したボード Altera DE2-115 Development and Education Board Cyclone IV EP4CE メモリ保護, マルチコアに対応 HWイメージのコンフィギュレーション情報ファイルをOSに同梱予定 42

43 OS のコンフィギュレーション法 ATK2 では,2 つの法をサポートディスクリプションファイル (XML) AUTOSAR 準拠のコンフィギュレーション記法 AUTOSAR のメソドロジでは, 上位レイヤからディスクリプションファイルを受け取って, 各モジュールのコンフィギュレーションをう不しているパラメータコンテナを独に追加が読み書きするのは困難静的 API(μITRON 仕様 ) μitron で規定されている静的 API の記法を元に, XML によるコンフィギュレーションと同等の機能を実現が読み書きするのも容易 43

44 テストスイートによる ATK2 の検証過去のコンソシーアム型共同研究で開発したテストスイートを AUTOSAR OS の検証に活したい TOPPERS 新世代カーネルを対象にしたテストスイートである TTSP(TOPPERS Test Suite Package) をベースに AKTSP(Automotive Kernel Test Suite Package) を開発補 :TOPPERS 新世代カーネル μitron 仕様をベースとして, 信頼性, 安全性, ソフトウェアポータビリティを向上させるために改良拡張シングルプロセッサ向けRTOS:TOPPERS/ASPカーネルマルチプロセッサ向けRTOS :TOPPERS/FMPカーネル 44

45 組み合わせテストツール検査対象 OS を μitron 仕様から AUTOSAR 仕様に変更 OS が提供するシステムサービスの数は減少したが仕様の複雑化によりテストとして考慮すべき組み合わせパターンが増タスクのコンフィギュレーションの組み合わせだけでも ASP の 4 倍 ASP カーネルのテストケース ATK2-SC1 のテストケース 1,669 件増加約 7,000 件従来のテスト開発プロセスでっていた組み合わせテストケースの動作成が困難に PictMaster( ) を使して組み合わせを動成! 45

46 テストプログラムの動成 PictMaster が成した CSV ファイルから動成形式化したテストシナリオテストシナリオを実現するテストプログラム前状態 < システムサービス発前のシステム状態 > 処理 < システムサービス発処理 > AKTG 出 test.arxml test.h test.c 後状態 < システムサービス発後のシステム状態 > TESRY 記法 (TEst Scenario for Rtos by Yaml) (Automotive Kernel Test Generator) Ruby で開発約 23,000 AKTG は TTSP で開発した TTG(TOPPERS Test Generator) をベースに開発 μitron ベースの RTOS 向けテストプログラム成ツール電情報通信学会論誌 D, Vol.J95-D, No.4, pp

47 テストケース数 SC1 SC3 シングルマルチコアシングルマルチコアコア追加分コア追加分システムサービステスト 6,841 23,303 37,717 82,862 MODISTARC エラー処理テスト不正終了 3,839-29,093 - スタックモニタリング保護違反時 CPU 例外処理テストメモリ保護 ( ) ,648 - タスク強制終了 - - 1,655 - IOCテスト - 3,710-11,736 合計 10,982 27, ,051 94,598 Nios2 の場合 (2013 年 5 現在 ) 47

48 ATK2 設計書および AKTSP の取り扱い外部仕様書, ソースコードのみオープンソースとし, 設計書, テストスイート (AKTSP) は公開しないコンソーシアム型共同研究参加企業のみが可能ただし, 希望する企業には有償でライセンス提供可能既に国内外の複数企業から問い合わせあり実際にライセンス提供を希望する企業もライセンス料は共同研究費の価格をベースに, 参加企業が不利にならない価格帯を設定ライセンス料は年度を跨ぐ毎に減額し, 最終的には無償で公開する予定 (5 6 年後 ) ご興味のあるはお問い合わせください atk2-conso-staff@nces.is.nagoya-u.ac.jp 48

49 Elektrobit 社製 tresos AutoCore 上での動作確認 ATK2 (SC1) <Elektrobit tresos 上の OS を ATK2 へ置き換えて動作することを確認ターゲットは,V850E2 プロセッサを使 49

50 次 1. AUTOSARとは 2. NCESの取り組み 3. AUTOSAR OS 4. TOPPERS/ATK2の紹介 5. COMスタック 6. RTE 7. まとめ 50

51 COM スタックとは SW-C Application Layer SW-C SW-C SW-C Runtime Environment (RTE) SW-C 間の通信は RTE のみでう BSW(Basic Software) OS System Services Memory Services Communication Services I/O Hardware Abstraction Complex Drivers 他の ECU との通信は COM を使 Onboard Device Abstraction Memory Hardware Abstraction Communication Hardware Abstraction Microcontroller Drivers Memory Drivers COM Drivers IO Drivers 例 )CAN 通信 Microcontroller 他の ECU とのデータ通信をう SW-C には通信プロトコルは隠蔽される部分的に OSEK/COM 仕様をベースとしている他の ECU へ 51

52 開発範囲 COMスタックすべての仕様は膨であるボディ系ドメインで使されるであろう機能に絞ったサブセットを対象とする通信プロトコルはCAN 通信のみとする対象バージョンはOS 同様,R4.0.3とする数に余裕があればマルチコアに対応するコンポーネント Com PduR CanIf Can(Driver) 機能信号ゲートウェイ機能 PDU(Protocol Data Units) のルーティング CAN 通信のみの場合, 実質不要 CANプロトコルコントローラと CANトランシーバの抽象化 CANの初期化,CANの出 <R4.0.3 AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf P.53 抜粋 > 52

53 開発法 Com 参加企業からのコントリビュート ( フルセット ) Com CT:Conformance Test AUTOSAR から公開されている R4.0.2 で公開終了 Com CT (R3.0.2) (R4.0.3) (R4.0.2) PduR (R3.0.2) CanIf (R3.0.2) R3.0.2 と R4.0.3 の変更点を修正ボディ系ドメインの機能のみ抽出 PduR (ZeroCost) CanIf (R4.0.3) CT によるテストドリブン開発 R4.0.2/R4.0.3 の仕様差分は僅か CT 実のためのツールを開発 CanIf CT (R4.0.2) Can (R3.0.2) (Nios2 に対応 ) そのまま使バージョン相違による弊害は無い NCES で過去に開発 Can (R3.0.2) 開発成果物 53

54 コンフォーマンステスト実法 AUTOSARから公開 R4.0.2 準拠テストシーケンス (*.ttcn) テストライブラリ (*.ttcn) パラメータファイル (*.par) ディスクリプションファイル (*.arxml) TTCN-3 というテスト語 TTCN ツールで対応するには膨なコストを要する独に変換ツールを開発 TTCN と等価の処理内容となる C/C++ コードへ変換変換ツール設定値チェックのデータ定義に使 R4.0.3 の仕様に合わせたディスクリプションファイルを作成変換ツール異なる形式で等価な情報を記載テストシーケンス (*.c cpp h) テストライブラリ (*.c cpp h) データ定義ファイル (*.c h) ディスクリプションファイル (*.arxml) テスト仕様書 (*.pdf) R4.0.2 のディスクリプションファイルは, パラメータが若異なるので使しない成したファイルを使し, Com/CanIf のテストを実 54

55 マルチコア仕様 (R4.0.3) <R4.0.3 AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf P.53 抜粋 > マスタコアでしか Com による通信ができないスレーブコアからの Com 通信がオーバーヘッドとなるマスタコアを毎回経由する必要がある 55

56 マルチコア仕様 (R4.1.1) <R4.0.3 AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf P.53 抜粋 > " マスタ - サテライト通信 " をサポート NCES で過去に同様の研究実績がある数に余裕があれば適したい 56

57 次 1. AUTOSARとは 2. NCESの取り組み 3. AUTOSAR OS 4. TOPPERS/ATK2の紹介 5. COMスタック 6. RTE 7. まとめ 57

58 RTE とは ECU1 ECU2 SW-C1 SW-C2 Application Layer SW-C3 SW-C4 SW-C5 SW-C6 Application Layer SW-C7 SW-C8 デバイスからの通知周期実 OS のシステムサービス呼出し ECU 内通信 RTE RTE ECU 間通信 BSW(Basic Software) BSW(Basic Software) OS System Services Complex Drivers Memory Services I/O Hardware Abstraction Communication Services OS System Services Communication Services Memory Services I/O Hardware Abstraction Complex Drivers コンフィギュレーション情報に従って, SW-C や BSW の実スケジューリングを制御するコンフィギュレーション情報に従って, 効率的な SW-C 間の通信を実現するコンフィギュレーション情報に従って, RTE ジェネレータから, 必要な API が成される RTE の実体は動成コードとなる 58

59 メソドロジ ( 実モジュールの成法 ) ステップ 1: システムコンフィギュレーションステップ 3: コンフィギュレーション情報を元に実モジュールを作成するステップ 2: ECU コンフィギュレーション <R4.0.3 "AUTOSAR_EXP_VFB.pdf" Figure 2.1> 59

60 システムコンフィギュレーション SW-C 間で使する I/F 通信やどの ECU で動作させるかを定義する VFB によって抽象化され,SW-C からは RTE より下位層はえない SW-C を実する ECU の指定, 必要な RTE API 情報等をディスクリプションファイルで成必要な I/F 通信に応じて, 最適な API が RTE ジェネレータによって成される <R4.0.3 "AUTOSAR_EXP_VFB.pdf" Figure 2.2> 60

61 ECU コンフィギュレーション SW-C RTE ディスク Runnable1 Runnable2 Runnable3 リプションファイル OS ディスク RTE リプションファイル Task1 Task2 OS Com ディスクリプションファイル : SW-Cは, 複数のRunnableと呼ばれるアプリケーション処理の単位で構成されるアプリケーション開発者はRunnableを開発するどのRunnableがOS 上のどのタスクで実されるか, 排他制御には何を使するか等を設定する RTE,OS のディスクリプションファイルを作成する同様にCom 等のBSW のディスクリプションファイルを作成する各ディスクリプションファイルをツールで成するかはユーザ依存 61

62 RTE の成システムディスクリプションファイルコンフィギュレーション情報に従って適切な関数やコードを成する Runnable1 SW-C Runnable2 RTE ディスクリプションファイル OS ディスク RTE ジェネレータ Runnable1 を実 RTE Rte_Send_p1_a(data) リプションファイル ActivateTask(Task1) Com_SendSignal (Signal1,data) Com ディスクリプションファイル Task1 OS Signal1 COM OSの機能を使して,Runnableのスケジューリングをう SW-Cから, どのECU 通信路を使しているかをえないように隠蔽する ( ラッパー関数を成する ) OS,COM ディスクリプションファイルは,OS,COMのジェネレータのとしても使する 62

63 開発状況 JasParにて開発実績のある企業への委託開発を予定対象バージョンはOS,COM 同様,R4.0.3とする対象とする仕様はCOMに合わせてボディ系ドメインのみ OSがマルチコアに対応することから, マルチコアに関する機能は追加する予定 2013 年 10 末に開発を完了し,OS COMとのインテグレーションを実施システム設計ツールはdSPACE 社製 SystemDesk4.0を使する予定最終的に,OS COMを合わせてTOPPERSプロジェクトからオープンソース化する 63

64 次 1. AUTOSARとは 2. NCESの取り組み 3. AUTOSAR OS 4. TOPPERS/ATK2の紹介 5. COMスタック 6. RTE 7. まとめ 64

65 まとめ AUTOSAR 仕様のプラットフォームを開発まずは,OS/COM/RTE を提供 OSはメモリ保護, マルチコアに対応タイミング保護のみ未サポート COM/RTEはボディ系ドメインに限定したサブセット最終的にオープンソースで提供する予定今後の展望 OSのタイミング保護対応 COM/RTEの機能拡充他のBSWの開発ご意ご質問のあるはお問い合わせください NCES ATK2 検索 65

AUTOSAR OSに対するテストケースおよびテストプログラムの自動生成

AUTOSAR OSに対するテストケースおよびテストプログラムの自動生成ソフトウェアテストシンポジウム 2012 JaSST'12: Japan Symposium on Software Testing 2012 AUTOSAR OS に対するテストケースおよびテストプログラムの自動生成 2012 年 1 月 25 日日本電気通信システム株式会社風間佳之 1 アジェンダ 1. はじめに 2. 既存のテストスイートの概要 3. テストスイート開発における課題 4.

名古屋 学組込みシステム研究センター (NCES) の AUTOSAR に対する取り組み 2013 年 8 23 ( ) 名古屋 学鴫原 1

名古屋学組込みシステム研究センター (NCES) の AUTOSAR に対する取り組み 2013 年 8 23 ( ) 名古屋学鴫原 1