検索
連載

AUTOSARの歴史と最新動向に見る、Classic PlatformとAdaptive Platformの関係：AUTOSARを使いこなす（6）（2/4 ページ）

車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載の第6回では、2018年11月時点でのAUTOSARの最新動向を紹介するとともに、Classic PlatformとAdaptive Platformの関係について説明する。

Share
Tweet
LINE
Hatena
前のページへ | 次のページへ

今回のリリース内容（1）：Classic Platform（CP） R4.4.0

　CPは、2005年6月にR1.0が発行され、R2.0は2006年中頃、R2.1は2006年末（その後約5年にわたり多数の改定あり）、R3.0.1は2007年末（その後2014年のR3.2.3まで多数の改定あり）、R4.0.1は2009年末に発行されました。R1.0からは13年、R4.0の最初のリリースから既に9年経ちましたが、今回のR4.4.0でもまだ多数の改訂や機能追加が行われています。

　ここでは、AUTOSAR CP R4.4.0 TR Classic Platform Release Overviewに基づき、概要をご紹介いたします。

　ちなみに今回、筆者はWP-A2（Communication Stack）とWP-X-SEC（Security）に参加しており、通信スタックのSRS／SWS文書（複数）のドキュメントオーナー（Document Owner）として改訂作業に当たり、また、SWS SecOC（Secure Onboard Communication）などの改訂にも関わりました。今後はFT-SAF／WP-A3（いずれもSafety）に軸足を移します。

　R4.4.0では、以下の11個のコンセプト提案が反映されました。うち6つは反映途上（Draft）であり、関連する要求項目には「DRAFT」と明記されています。

  1. ASAMUnits
    • ASAM（Association for Standardization of Automation and Measuring Systems）で定義された物理量に関するデータ型が取り込まれ、ASAMで規定されたデータ形式とAUTOSARのそれとの互換性が高まりました
  2. AUTOSARRunTimeInterface（ARTI） ※Draft
    • OSEK/VDXにおけるOSEK Run Time Interface（ORTI、ISO化されていません）と同様に、Runnable/Portレベルでのデバッグ支援をするための拡張です
    • なお、ORTIはシングルコアを想定したものですが、ARTIはマルチコアも想定しています
  3. RTEImplementationPlugIns ※Draft
    • RTEでは標準的に対応されないような機能の拡張や、独自のトランスフォーマー（Transformer）の呼び出し、排他制御、Runtime／RAM利用効率の最適化などを個別に行えるようにするための拡張です
  4. LINSlaveSupport
    • これまで、LIN Slave ECUはAUTOSARアーキテクチャ上では対応されていませんでしたが、R4.4.0から対応しました
    • なお、これとあわせて、参照される通信規格を、すでに解散し公式Webサイトが閉鎖されているLINコンソーシアムの仕様書から、ISO 17987シリーズに切り替えました。細かな矛盾や不備の多くも解消されました
  5. Formal Model Query and Blueprint Derivation Mechanisms ※Draft
    • AUTOSAR Model Query Language（ARMQL）と呼ばれる言語を導入し、SWSなどにおけるvariation pointの記述方法をAP／CPで共通化し、可読性を高めます
  6. BusMirroring
    • 車外や診断コネクターから直接アクセスできない車内通信（In-Vehicle Communication、IVC）の内容を、ゲートウェイECU（Gateway）を介してモニターできるようにするための拡張です
    • CANにおけるエラーカウンタ（Error Counter）の値なども参照できます
    • なお、これを使用する際には、診断やXCPと同様に、あらかじめ帯域予約しておく必要があることに注意が必要です
  7. SecurityExtensions
    • セキュリティ関連のBSW群の動作制御を可能にするための各種拡張です
    • ここには、secure logging、vehicle key and certificate management、authentic timeおよびdiagnostic policy managementを含みます
  8. MCALMulticoreDistribution ※Draft
    • これは、MCAL（Microcontroller Abstraction Layer）のBSWモジュールをマルチコア環境で利用しやすくするための拡張です
    • マルチコアのマイコンでMCALを使用する場合、複数コアからAPIを利用できるか否か、APIの実行がどのコアで行われるか、周辺機能を複数コアに割り付けることができるかなどの、MCALとしてのマルチコア対応の有無やその方式の把握が必要となりますので、その表現方法が規定され、あわせてパーティションへの割付設定ができるようになりました
  9. Logical Execution Time（LET）
    • ある1つ以上のRunnableで行われる一連の処理の｛入力−演算−出力｝のブロックにおける入力と出力のタイミングを変化させないようにすることで、性能の異なるマイコンを使用したとしても、処理負荷率が変化するだけで動的な振る舞いの変化を防ぐというスケジューリング手法（LET）を、ツールで実現するための拡張です
  10. TransportLayerSecurity ※Draft
    • イーサネット通信におけるセキュリティプロトコルであるTransport Layer Security（TLS）に対応しました
  11. Extended Serialization for Data Structures in SOME/IP with tag/length/value encoding ※Draft
    • SOME/IPにおけるtag/length/value encoding（TLV）への対応です
    • 例えば、ECU間のクライアント／サーバ通信の実現においては、SOME/IPのSerialization（引数のバイト列への変換）が行われます
    • しかし、サーバ側ECUが機能追加されることによって、クライアントから引き渡し可能な引数が増えたような場合、クライアント側ECUを更新しない限り、クライアント／サーバ間ではSerializeされたバイト列の解釈が食い違ってしまいます
    • このような扱いにくさを解消し、ECUのアップデートを円滑に行えるようにするために、各引数に管理情報をつけ、たとえサーバとクライアントでソフトウェアの世代が異なり引数の数が異なっていたとしても、管理情報により対応付けることで通信可能となるようにしています

　これらのコンセプトの他にも、例えば、以下のような変更が行われています。

  • SecOC：受信内容検証結果に異常があった場合の対処の選択肢の追加
  • CanIf：受信DLCチェックをPDU単位で行えるように拡張
  • CanTp：半二重モードの削除
  • 通信スタック：CancelTransmit API削除
  • Crypto Stack：SecureCounterの削除

　また、地味な部分ではヘッダファイル構造の大幅見直しなども行われています。なお、このような規模の大きな変更の際にはミスが付き物ですので、おかしいなとお感じになったときには、素直に「これ、おかしいのでは？」という報告をしたほうが良いでしょう。

　ちなみに日本では、なぜか問い合わせもせずに変に裏読み／理由付けをして納得してしまう、という現象もしばしば見かけます（私は「こじらせAUTOSAR」と呼んでいますが、これも、心理学における正常性バイアス（normalcy bias）の一種と考えられます）。Associate Partnerの方は、直接AUTOSARに報告する手段がございませんが、必要であれば取りあえず私にご相談いただければと思います。

　なお、追加／削除などが行われたモジュールは以下の通りです。

  • 追加：KeyM、Mirror
  • 削除：EcuM（fixed）、Cal
  • Obsolete設定（次のマイナーリリースで削除予定）：LinNm

　また、TR Technical Safety Concept Status Reportについても、すでにメンテナンスが中止されており、今回削除されています。

Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ | 次のページへ
ページトップに戻る