名古屋⼤学
組込みシステム研究センター(NCES)のAUTOSAR に対する取り組み

2013年8⽉23⽇(⾦)

名古屋⼤学 鴫原 ⼀⼈
1

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

⾞載ソフトウェアの課題と再利⽤性の向上
⾃動⾞の製造コストに占める電⼦部品の割合
2007年：20〜30％↓
2015年：40％

ソフトウェアの再利⽤性向上が急務
どのOEMへも提供可能としたい

OEM A

サプライヤ開発
ソフトウェア

OEM B

OEM C
3

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

http://www.autosar.org/
4

AUTOSARのコンセプト
従来

AUTOSAR
アプリケーション

アプリケーション
ハードウェア

標準化インタフェース

AUTOSAR
HW依存インタフェース
ハードウェア"Cooperate on standards, compete on implementation"

メーカーやハードウェアに依存するインタフェース，コンフィギュレーションを標準化
ソフトウェアの再利⽤性が向上し，開発コストの低減も実現される
5アーキテクチャ
SW-C

Application Layer

SW-C

SW-C

SW-C

Runtime Environment (RTE)
BSW(Basic Software)
SystemServices

MemoryServices

Communication
Services

OnboardDeviceAbstraction

MemoryHardwareAbstraction

Communication
HardwareAbstraction

Microcontroller
Drivers

MemoryDrivers

COM Drivers

I/O Hardware
Abstraction

Complex
Drivers

OSIO Drivers

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

SW-C

SW-C

Application Layer

SW-C

SW-C

Runtime Environment (RTE)7

BSW• RTEからの要求に対して，マイコンを制御するまでの処理を階層構造によって抽象化するためのコンポーネント群• ほとんどのBSWはOS上で動作するため，SW-C，RTEも最終的にはOS上で動作する
サービス層

RTE

ECU抽象化層

BSW(Basic Software)
SystemServices

MemoryServices

Communication
Services

I/O
HardwareAbstraction

Complex
Drivers

マイコン抽象化層

OS
OnboardDeviceAbstraction

MemoryHardwareAbstraction

Communication
HardwareAbstraction

Microcontroller
Drivers

MemoryDrivers

COM Drivers

IO Drivers

Microcontroller

8想定される開発対象者
SW-C

Application Layer

SW-C

SW-C

SW-C

• ⾃動⾞メーカ• 部品メーカ

Runtime Environment (RTE)
BSW(Basic Software)
SystemServices

MemoryServices

Communication
Services

OnboardDeviceAbstraction

MemoryHardwareAbstraction

Communication
HardwareAbstraction

Microcontroller
Drivers

MemoryDrivers

COM Drivers

I/O
HardwareAbstraction

Complex
Drivers• 部品メーカ• ツールベンダ

OS

Microcontroller

OSのターゲット依存部は・・？
(インターフェイスが未規定)

IO Drivers• 半導体メーカ

標準化により部品化が可能となり再利⽤性が向上する
9ロードマップ

NCESではR4.0.3に準拠して開発を実施

2013年4⽉9⽇にリリースされた<5th AUTOSAR Open Conference>10

AUTOSAR導⼊のメリット・デメリット”全領域”とは？
AUTOSARで規定されているXML仕様は⼗分でない

⾞載ソフトウェアでは致命的な問題<MONOist http://monoist.atmarkit.co.jp/mn/articles/0910/01/news123.html>
11⽬次
1. AUTOSARとは
2. NCESの取り組み
3. AUTOSAR OS
4. TOPPERS/ATK2の紹介
5. COMスタック
6. RTE
7. まとめ12

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

①AUTOSAR OS仕様の実装/評価
プロジェクト概要 (2008年度〜2010年度)• Release 4.0の仕様の明確化と修正• NCES独⾃のマルチコア拡張• 必要性とオーバヘッドのトレードオフを考慮するため，機能レベル(後述)を定義

成果物

プロトタイプOSを実装し，仕様の妥当性を評価
これらの成果を活かしてオープンソースで提供したい• 外部仕様書• OSEK/VDX仕様を統合した1つのドキュメント• 全仕様を⽇本語で記載• OSソースコード(SC1，SC2，SC3，SC1-MC，SC3-MC)• 未実装の機能あり• AUTOSAR仕様の曖昧な点に対する⼗分な検討は未実施• 単体評価スイート(機能評価，性能評価)• ⼗分な検証は未実施

14

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

15

コンソーシアム型研究組織とは名古屋⼤学 組込みシステム研究センターが設定した研究テーマに対して，複数の企業・団体が参加し共同で研究・開発を⾏う
教員／研究者

コンソーシアム型
研究組織
企業の経験／知⾒

研究者／技術者(共同研究員)･⼈材育成･ビジネス発展

産学官連携による技術課題の解決
名古屋⼤学
組込みシステム研究センター(NCES)

参加企業
16

参加企業と⼈数(2013年5⽉時点)
企業名

常駐研究協⼒(株)ヴィッツ

1

5(株)永和システムマネジメント

03(株)OTSL02(株)サニー技研

15(株)デンソー

010(株)東芝

13

トヨタ⾃動⾞(株)03(株)豊⽥⾃動織機

06

パナソニックアドバンストテクノロジー(株)13

富⼠ソフト(株)37

ルネサスエレクトロニクス(株)

16

合計

853

上記の他，名⼤教員・研究員が3〜4名実作業に参加
17

ロードマップ※機能拡張2011年度SC1OS開発→テストスイートも併せて開発

SC3

2012年度

2013年度

仕様検討
SC3※
SC1-MC
SC3-MC
トレーサビリティ

MC/DC解析

評価
COMスタック開発
RTE開発

Com，CanIf
評価
RTE
評価
18

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

スケーラビリティクラス• 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⽉末に公開予定

http://www.toppers.jp/atk2.html
20

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

AUTOSARとOSEK/VDX

OSEK/VDX準拠で開発

OSEK/VDX仕様※Version2.2.3

上位互換とする→差分仕様のみ記載

できる限り再利⽤したい

AUTOSAR準拠で開発

AUTOSAR OS仕様
実際はSW-Cでは・・？

22

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

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

24

次世代⾞載システム向けRTOS外部仕様書の作成

OSEK/VDX仕様

AUTOSAR OS仕様

外部仕様書

• ⽇本語化• OSEK/VDX仕様に加え，AUTOSAR OS仕様で追加/修正された仕様をマージ• トレーサビリティを⾒据えて仕様にタグを付与• 未定義，曖昧な仕様に対してはNCES独⾃仕様を追加• OSの実装に依存した仕様も記載

25

トレーサビリティを⾒据えた仕様タグ
仕様タグ凡例【COSxxxx】：OSEK仕様(独⾃にタグを付番)【OSxxx】 ：AUTOSAR仕様(原⽂に付与されているタグ)【OSaxxx】 ：AUTOSAR仕様(仕様タグが付与されていない)【NOSxxxx】：NCES独⾃仕様【IOSxxx】 ：実装依存仕様【DOSxxx】 ：設計仕様※〔仕様タグ〕は【仕様タグ】の参照と定義
テストデータ
テスト対象
仕様タグ- COSxxx- OSxxx

次世代⾞載システム向け
RTOS外部仕様書○○○【COS123】

どの仕様に対するテストデータかを管理

外部仕様書のどの仕様を基に設計・実装したかを管理可能
ATK2設計書△△△【DOS789】〔COS123〕

OSソースコード/* DOS789 */26

仕様タグの件数
仕様種別

外部仕様書
(514ページ)

件数

COS

427

OS

620

OSa

177

NOS

803

IOS

223

合計

2,264(2013年6⽉末公開版)

外部仕様書の2,264件の内，NOSとIOSを合わせて1,026件
OSEK，AUTOSARに，数多くある曖昧な仕様や実装依存となっている仕様を明確に規定した27

追加した仕様の内訳
種別件数

曖昧，未規定のために追加した仕様
NOS
803件 ⾼オーバーヘッドのために追加/改変した仕様

364
219

品質を向上するために追加した仕様

220

AUTOSAR仕様の品質は良いとは⾔えない・・・

28

OSEK/VDX仕様との⽭盾の例
OSEK仕様OSEKでは，E_OS_VALUEは拡張エラーと規定されている

AUTOSARでは，標準エラーと規定されている

AUTOSAR仕様

標準エラーはデバッグ済みのアプリケーションでも起こりうるエラーを対象としているため，AUTOSARの誤記と判断
29

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

OSEK仕様■実⾏中のタスクIDを取得する
StatusType GetTaskID(TaskRefType TaskID);

AUTOSAR仕様■実⾏中のISR IDを取得する
ISRType GetISRID(void);

タスクIDを受け取る変数のポインタを引数に渡し，実⾏結果が戻り値となる

実⾏結果がISR IDとなるため，実⾏状態のISRが存在しないかエラーが発⽣したか区別不可(しかもエラーフックは呼ばれない)

返り値が無効値となる場合など，エラーフックが呼び出されるべき状況があるため，返り値の型がStatusTypeでないシステムサービス
でも，エラーフックが呼び出される場合があることを規定
30

NCES独⾃仕様
曖昧な仕様
SC1でのプロテクションフックの扱い

SC1でCPU例外が発⽣したらどうなる？
SC1でもCPU例外やスタックオーバーフローが発⽣した際にはプロテクションフックを呼び出すように規定

未定義である仕様
OSが管理するスタック設定

OSEK，AUTOSAR共に，スタック設定に関する記述がない
OSで管理するスタックの種類と，スタックのコンフィギュレーションについて規定
31

OSアプリケーション(OSAP)とは『アプリケーション毎に分割した複数のOSオブジェクトの集合』
⾮信頼OSAP

アクセス
禁⽌(※)

タスク
アクセス
許可

⾮信頼OSAP

アクセス
禁⽌(※)

タスク
アクセス
禁⽌(※)

アクセス
許可

信頼OSAP

タスクアクセス許可アクセス許可タスク

タスク

タスク

カウンタ

アラーム

データ領域

※アクセス権を付与することでアクセス可能となる

32

OSAPに対して提供する機能
OSAPの終了処理再起動も可能

信頼OSAP終了状態となる
⾮信頼OSAPOSAP強制終了

タスク

タスク

信頼関数
信頼OSAP

信頼関数

I/O領域など

信頼関数実⾏⾮信頼OSAPタスク

⾮信頼OSAPからアクセス可能となる
33

メモリ領域に対する保護と保護違反時の機能保護違反からの復旧処理をユーザが選択可能
例1)

プロテクションフック

タスク(ISR)のみを強制終了

OSシャットダウンも可能

起動

⾮信頼OSAP

信頼OSAP
アクセス違反発⽣

タスク/ISR

例2)

データ領域

プロテクションフック
OSアプリケーションごと強制終了

OSシャットダウンも可能

起動

⾮信頼OSAP

信頼OSAP
アクセス違反発⽣

タスク/ISR

データ領域
34

メモリ保護機能の問題点①
リソース獲得中のOSAP強制終了
他のOSAPに含まれるリソースを取得していた場合そのOSAPが強制終了されるとリソースはどうなるのか？
OSAP強制終了
TerminateApplication()
信頼OSAP2

タスク2

⾮信頼OSAP

リソース獲得中

信頼OSAP1

タスク1• リソースが強制解除される？
• 排他制御が崩れる可能性あり• タスク1がリソースを解放するまで待つ？
• タスク2がそれまで待たされる？
• OSAP終了処理を低優先度で継続？

AUTOSAR R4.0.2 → R4.0.3で解決→リソースはOSAPに所属しなくなった35

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

(⾮信頼)ISR2(⾮信頼)ISR1t

ISR2が強制終了された場合にISR1へ戻るための情報をすべて保持する必要がある→⾼オーバーヘッド36

メモリ保護機能の問題点③信頼関数，信頼OSAPの終了• 信頼関数実⾏中に終了してよいか？
• 信頼OSAPを強制終了する意義はあるか？
信頼OSAP1

信頼関数

信頼関数実⾏中CallTrustedFunction()

⾮信頼OSAPタスク

OSAP強制終了可能
TerminateApplication()

I/O領域などデータの⼀貫性などが保証できない可能性がある

信頼OSAP2

タスク2
37

機能レベルの導⼊メモリ保護の機能レベル• 機能レベル1• ⾮信頼OSAPに所属するタスクをサポート

ATK2では機能レベル2を採⽤！

• 機能レベル2• ⾮信頼OSAPに所属するフックルーチンをサポート• 機能レベル3• ⾮信頼OSAPに所属するISRをサポート

保護違反⾃処理の機能レベル• 機能レベル1• 保護違反時，OSシャットダウンをサポート• 機能レベル2• 保護違反時，タスクの強制終了をサポート

⾮信頼OSAPの強制終了,再起動のみサポートする(2013年9末予定)• 機能レベル3• 保護違反時， ISRの強制終了，OSAPの強制終了/再起動をサポート

38

スピンロックとは• マルチコアにおいて，異なるコアのタスク，ISR間の排他制御に⽤いるOSオブジェクト• 他のコアで獲得されたスピンロックを獲得しようとした場合，スピンロックが解放されるまでビジーウェイトする• AUTOSAR仕様ではスピンロック獲得中に割込み禁⽌としない• デッドロック対策⽤のエラーが2つ⽤意されている
エラー1
同じコアのタスク/ISRが獲得しているスピンロックを獲得しようとした場合

エラー2
コンフィギュレーション時に指定した獲得順序を守らずにスピンロックを獲得しようとした場合

⾼Task1

低Task2

実⾏中

Task2(Core2)

実⾏中

SPN1
スピンロック獲得(エラーとなる)

SPN1

優先度

Task1
(Core1)

デッドロック発⽣

Task2がSPN1を解放前にTASK1が起動

スピンロック獲得

獲得順序設定：SPN1→SPN2

実⾏中
実⾏中

SPN1

SPN2

SPN1

SPN2
スピンロック獲得(エラーとなる)39スピンロックの問題点
獲得順序設定：SPN1→SPN2
⾼低Task1-1(Core1)

Task1-2がSPN1を解放前にTASK1-1が起動

Task1-2(Core1)

実⾏中

デッドロック発⽣

実⾏中SPN2
スピンロック獲得(エラーとならない)

SPN1

優先度
⾼低

Task2-1(Core2)

Task2-2がSPN1を解放前にTASK2-1が起動

Task2-2(Core2)

実⾏中

SPN2

デッドロック発⽣

実⾏中SPN1
スピンロック獲得(エラーとならない)

優先度• 獲得順序エラーは同じタスク/ISRに対してのみ有効であるので上図のシーケンスで発⽣するデッドロックは防⽌できない• スピンロック獲得時は割込み禁⽌とすれば本デッドロックは発⽣しない• NCES独⾃仕様で割込み禁⽌を伴うスピンロック仕様を策定

R4.1.1で同様のスピンロックが導⼊された40

⽬次
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(ルネサスエレクトロニクス)• SC1-MC，SC3-MC(機能レベル2)を2013年6⽉に公開予定
開発に使⽤したボード• Altera DE2-115 Development and Education Board• Cyclone IV EP4CE• メモリ保護，マルチコアに対応• HWイメージのコンフィギュレーション
情報ファイルをOSに同梱予定

42

OSのコンフィギュレーション⽅法
ATK2では，2つの⽅法をサポート

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

テストスイートによるATK2の検証
過去のコンソシーアム型共同研究で開発したテストスイートをAUTOSAR OSの検証に活⽤したい…

TOPPERS新世代カーネルを対象にしたテストスイートであるTTSP(TOPPERS Test Suite Package)をベースにAKTSP(Automotive Kernel Test Suite Package)を開発
補⾜：TOPPERS新世代カーネル

μITRON仕様をベースとして，信頼性，安全性，ソフトウェアポータビリティを向上させるために改良・拡張
シングルプロセッサ向けRTOS：TOPPERS/ASPカーネル
マルチプロセッサ向けRTOS ：TOPPERS/FMPカーネル

44

組み合わせテストツール
検査対象OSをμITRON仕様からAUTOSAR仕様に変更
OSが提供するシステムサービスの数は減少したが…
仕様の複雑化によりテストとして考慮すべき組み合わせパターンが増⼤→タスクのコンフィギュレーションの組み合わせだけでもASPの4倍
ASPカーネルのテストケース

1,669件ATK2-SC1のテストケース

増加

約7,000件

従来のテスト開発プロセスで⾏っていた組み合わせテストケースの⼿動作成が困難にPictMaster(※)を使⽤して組み合わせを⾃動⽣成！
※ http://sourceforge.jp/projects/pictmaster/45

テストプログラムの⾃動⽣成
PictMasterが⽣成した
CSVファイルから⾃動⽣成テストシナリオを実現するテストプログラム形式化したテストシナリオ
前状態＜システムサービス発⾏前のシステム状態＞

処理＜システムサービス発⾏処理＞

後状態＜システムサービス発⾏後のシステム状態＞

⼊⼒

出⼒
AKTG

test.arxml
test.htest.c(Automotive Kernel TestGenerator)
・Rubyで開発
・約23,000⾏TESRY記法(TEst Scenario for Rtos by Yaml)

AKTGはTTSPで開発したTTG(TOPPERS Test Generator)をベースに開発『μITRONベースのRTOS向けテストプログラム⽣成ツール』
電⼦情報通信学会論⽂誌D, Vol.J95-D, No.4, pp.870--88446

テストケース数SC1

システムサービステスト
MODISTARC
エラー処理
テスト

保護違反時処理テスト

IOCテスト合計※Nios2の場合

不正終了
スタック
モニタリング
CPU例外
メモリ保護(※)
タスク
強制終了

SC3

シングル
コア

マルチコア
追加分

シングル
コア

マルチコア
追加分

6,841

23,30337,71782,862

66

－

83

3,839

－

29,093－

240－

790－

62－

148

－

－

－

42,648－－－

1,655－

－

3,710

－

11,736

10,98227,013112,051

94,598(2013年5⽉現在)
47

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

Elektrobit社製 tresos AutoCore上での動作確認

ATK2
(SC1)

<Elektrobit http://automotive.elektrobit.com/>• tresos上のOSをATK2へ置き換えて動作することを確認• ターゲットは，V850E2プロセッサを使⽤
49

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

COMスタックとはApplication Layer

SW-CSW-C

SW-C

I/O
HardwareAbstraction

SW-C

Runtime Environment (RTE)

SW-C間の通信はRTEのみで⾏う

BSW(Basic Software)
SystemServices

MemoryServices

Communication
Services

OnboardDeviceAbstraction

MemoryHardwareAbstraction

Communication
HardwareAbstraction

Microcontroller
Drivers

MemoryDrivers

COM Drivers

OSIO Drivers

Complex
Drivers

他のECUとの通信はCOMを使⽤例)CAN通信

Microcontroller• 他のECUとのデータ通信を⾏う• SW-Cには通信プロトコルは隠蔽される• 部分的にOSEK/COM仕様をベースとしている

他のECUへ51

開発範囲• COMスタックすべての仕様は膨⼤である• ボディ系ドメインで使⽤されるであろう
機能に絞ったサブセットを対象とする• 通信プロトコルはCAN通信のみとする• 対象バージョンはOS同様，R4.0.3とする• ⼯数に余裕があればマルチコアに対応するコンポーネント機能

Com

信号ゲートウェイ機能

PduR

PDU(Protocol Data Units)のルーティング※CAN通信のみの場合，実質不要

CanIf

CANプロトコルコントローラとCANトランシーバの抽象化

Can(Driver)

CANの初期化，CANの⼊出⼒<R4.0.3 “AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf” P.53 抜粋>
52

開発⼿法

Com
(R3.0.2)
PduR(R3.0.2)
CanIf(R3.0.2)

Can(R3.0.2)(Nios2に対応)

参加企業からのコントリビュート(フルセット)

CT：Conformance Test

※AUTOSARから公開されている※R4.0.2で公開終了

Com(R4.0.3)• CTによるテストドリブン開発• R4.0.2/R4.0.3の仕様差分は僅か• CT実⾏のためのツールを開発

PduR• R3.0.2とR4.0.3の変更点を修正• ボディ系ドメインの機能のみ抽出

そのまま使⽤※バージョン相違による弊害は無い

NCESで過去に開発

Com⽤CT(R4.0.2)(ZeroCost)

CanIf(R4.0.3)

CanIf⽤CT(R4.0.2)

Can(R3.0.2)

開発成果物
53

コンフォーマンステスト実⾏⽅法
AUTOSARから公開
R4.0.2準拠

テストシーケンス(*.ttcn)
テストライブラリ(*.ttcn)
パラメータファイル(*.par)

ディスクリプション

ファイル(*.arxml)
テスト仕様書(*.pdf)• TTCN-3というテスト⽤⾔語• TTCNツールで対応するには膨⼤なコストを要する• 独⾃に変換ツールを開発
TTCNと等価の処理内容となるC/C++コードへ変換

変換ツール• 設定値チェック⽤のデータ定義に使⽤• R4.0.3の仕様に合わせたディスクリプションファイルを作成

変換ツール
異なる形式で等価な情報を記載
R4.0.2のディスクリプション
ファイルは，パラメータが若⼲異なるので使⽤しない

テストシーケンス(*.c|cpp|h)
テストライブラリ(*.c|cpp|h)データ定義ファイル(*.c|h)ディスクリプション
ファイル(*.arxml)

⽣成したファイルを使⽤し，Com/CanIfのテストを実⾏
54

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

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

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

RTEとは
ECU2

ECU1
SW-C1

SW-C2

デバイスからの通知

Application Layer

SW-C3

SW-C4

SW-C5SW-C6

Application Layer

OSのシステム
サービス呼出し周期実⾏SW-C7SW-C8

ECU内通信RTE

RTE

ECU間通信BSW(Basic Software)

BSW(Basic Software)
SystemServicesOS

Complex
Drivers

MemoryServices

I/O
HardwareAbstraction

SystemServices

Communication
ServicesOS

Communication
Services

MemoryServices

I/O
HardwareAbstraction

Complex
Drivers• コンフィギュレーション情報に従って，SW-CやBSWの実⾏スケジューリングを制御する• コンフィギュレーション情報に従って，効率的なSW-C間の通信を実現する• コンフィギュレーション情報に従って，RTEジェネレータから，必要なAPIが⽣成される• RTEの実体は⾃動⽣成コードとなる
58メソドロジ(実⾏モジュールの⽣成⽅法)
ステップ1：
システムコンフィギュレーション
ステップ3：
コンフィギュレーション情報を元に実⾏モジュールを作成する

ステップ2：
ECUコンフィギュレーション<R4.0.3 "AUTOSAR_EXP_VFB.pdf" Figure 2.1>59

システムコンフィギュレーション
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

ECUコンフィギュレーション
SW-C
Runnable1

Runnable2

Runnable3

・・・

OS⽤ディスクリプションファイル

RTE

Task1

Task2

OS

RTE⽤ディスク
リプションファイル

・・・

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

RTEの⽣成

システムディスク
リプションファイル
RTE⽤ディスク
リプションファイル
OS⽤ディスクリプションファイル
Com⽤ディスク
リプションファイル

コンフィギュレーション
情報に従って適切な関数やコードを⽣成する

SW-C
Runnable1

Runnable2

Rte_Send_p1_a(data)

Runnable1を実⾏

RTE
ジェネレータ・・・

RTE
ActivateTask(Task1)

Task1

OS…

Com_SendSignal(Signal1,data)

Signal1…

COM• OSの機能を使⽤して，Runnableのスケジューリングを⾏う• SW-Cから，どのECU・通信路を使⽤しているかを⾒えないように隠蔽する(ラッパー関数を⽣成する)• OS⽤，COM⽤ディスクリプションファイルは，OS，COMのジェネレータの⼊⼒としても使⽤する
62

開発状況
• JasParにて開発実績のある企業への委託開発を予定• 対象バージョンはOS，COM同様，R4.0.3とする• 対象とする仕様はCOMに合わせてボディ系ドメインのみ• OSがマルチコアに対応することから，マルチコアに関する機能は追加する予定• 2013年10⽉末に開発を完了し，OS・COMとのインテグレーションを実施• システム設計ツールはdSPACE社製SystemDesk4.0を使⽤する予定• 最終的に，OS・COMを合わせてTOPPERSプロジェクトからオープンソース化する63⽬次
1. AUTOSARとは
2. NCESの取り組み
3. AUTOSAR OS
4. TOPPERS/ATK2の紹介
5. COMスタック
6. RTE
7. まとめ64

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

検索65