AUTOSARにおける標準化活動とはどんなものなのか:AUTOSARを使いこなす(10)(3/3 ページ)
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載の第10回では、あまり知られていないAUTOSARにおける標準化活動について、筆者の経験を基にその一端を紹介する。また、AUTOSAR Adaptive Platformの最新リリースであるR19-03の変更点についても取り上げる。
AP R19-03における変更点
アーキテクチャ面:Adaptive Platform Foundation
- ara::com Communication Management(CM)
- Sampleでのリソース割当が無制限に行われないようにするための変更など、インタフェース構造の変更が行われました
- ara::rest RESTful
- REST通信に関しての変更はありません。
- ara::tsync Time Synchronization
- APIに変更があります。
- AUTOSAR metamodelのport prototypeの考え方とまだ整合できておらず、また、InstanceSpecifier対応もまだです
- ara::per Persistency
- 複数スレッドでの並行動作への対応が行われ、あわせてAPIが見直されました(特に、Persistent DataのInstallationとUpdateおよびFileProxyAccessorFactoryからFileStorage classへの名称変更)
- ara::phm Platform Health Management(PHM)
- PHMは、Multiple processes/multiple instances対応を含め、APIの大幅見直しが行われました
- RS Health Management/SWS Health Managementは、R1.5.0ではリリースが見送られ、その前のR1.4.0のものが公開されていましたが、R19-03にあわせてようやく改訂版がリリースされました
- なお、Daisy chainingなどの未対応機能が残っており、また、PHM/SM間のインタフェースにはまだまだ問題があります
- ara::core Core Types
- ResultのAPI型の規定が追加されました
- ara::exec Execution Management(EM)
- EM/SM間のインタフェースが見直されました
- なお、R18-10同様に、Resource LimitationとFault Toleranceについてはまだ完全な状態ではなく、Trusted Platformへの対応もまだ行われていません
- ara::iam Identity and Access Management(IAM)
- アクセス制御のための新しい要素Grantが導入されました
- ara::log Log and Trace(L&T)
- 構造の見直しが行われ、API構成も変更されました(Logstream, LogmanagerおよびLoggingの各class)
- ara::crypto Cryptography
- API設計が大幅に見直されました
- POSIX PSE51 / C++ Standard Template Library(STL):Operating System Interface
- POSIX PSE51インタフェースが、IEEE 1003.13-2003規格に基づくものだと明記されたくらいで、大きな変更はありません
アーキテクチャ面:Adaptive Platform Services
- ara::sm State Management(SM)
- SMについては、RSレベルでの要求が大きく見直され、他のFCとのインタフェースが大きく変化しています
- ara::diag Diagnostics, Diagnostic Management(DM)
- 診断関連のこの部分では、今回、ara::diagのインタフェースが公開されました。ただし、まだdraft状態です
- 機能面での大きな変化はありません。もちろん、OBD/WWH OBD(ISO 15031/ISO 27145)への対応はいまだ行われていません。
- ara::s2s Signal to Service Mapping
- R18-10と同様に、R19-03でも動作に関する記述は追加されないままです
- ara::nm Network Management(NM)
- PNC(Partial Network Cluster)、VLAN(Virtual Local Area Network)やChannelのグループ化が可能になりました
- ara::ucm Update and Configuration Management(UCM)
- Package Management関連のステートマシンの見直しが行われています(draft)
- また、リセット耐性に関する要求事項が増えています。
アーキテクチャ面以外
アーキテクチャ面以外の主要な変更としては、以下があります。
- Guidelines for the use of the C++14 language in critical and safety-related systems(参考文献[2])
- 本文書はMISRAに移管されることになり、AUTOSARでの安全関連WGを中心としてのメンテナンスは終了し、obsoleteのマークが付きました
- さらなる検討の後、いずれ遠くないうちにMISRA C++:2008の後継版としてリリースされることになるでしょう
なお、Methodology面での変化はありません。
終わりに
前項でトレーニングに関して少し触れましたので、次回はこの機会を利用して、組織的な人材育成面に目を向けてみたいと思います。
一般に「Basic/入門コース」などと銘打った教育コースは世の中に幾つもあります。ただ、受講した方々、そして、その上司の方々がお持ちになるご不満の1つが、「受講しても、一体、何ができるようになる/なっているのか、さっぱり分からない!」なのだそうです。
「コース設計」だけでは対処が難しい部分もあり、筆者が抱いている懸念と対処案をご紹介したいと考えています(内容変更の場合にはご容赦ください)。
次回以降に関しては、これ以外のテーマはまだ固まっておりませんので、ご要望などお寄せいただけますと幸いです。
また、2019年秋のリリースについては、AUTOSARの外部への明確なアナウンスは行われていませんが、例えば、Release Overviewの中では「next release (R19-11)」として触れられています。
リリースの種類や内容についてはまだ何も申し上げられませんが、どのような機能追加や変更が行われるのかなどについて、今度はリリースの後できるだけ早い段階でご紹介できるように準備したいと思います(間に合わなかったらご容赦ください)。
参考文献
[1]AUTOSAR AP R19-03 Adaptive Platform Release Overview
[2]AUTOSAR AP R19-03 Guidelines for the use of the C++14 language in critical and safety-related systems
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- ≫連載「AUTOSARを使いこなす」バックナンバー
- ≫連載「AUTOSAR〜はじめの一歩、そしてその未来」バックナンバー
- AUTOSAR Adaptive Platformのメソドロジ
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載の第9回では、前回取り上げたAUTOSAR Adaptive Platformのアーキテクチャに続いてメソドロジについて説明する。 - AUTOSAR Adaptive Platformのアーキテクチャ
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載の第8回では、新たに登場したAUTOSAR Adaptive Platformのアーキテクチャについて説明する。 - AUTOSAR Adaptive Platformとは?
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載の第7回では、AUTOSAR Classic Platformに次いで新たに登場したAUTOSAR Adaptive Platformについて説明する。 - AUTOSARの歴史と最新動向に見る、Classic PlatformとAdaptive Platformの関係
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載の第6回では、2018年11月時点でのAUTOSARの最新動向を紹介するとともに、Classic PlatformとAdaptive Platformの関係について説明する。