連載
» 2019年06月17日 10時00分 公開

AUTOSARを使いこなす(10):AUTOSARにおける標準化活動とはどんなものなのか (2/3)

[櫻井剛,MONOist]

AUTOSARの標準化作業における日本勢の存在感

 今回の会合では、日本からの参加者を多く見かけ、存在感が以前よりも大きくなってきたように感じられました。多少ですがホッとした気分にはなりました(それでも全出席者の1割には満たない人数でしたが……。そして、相変わらずdocument ownerの人数と担当文書数は少ないままです)。特に、これまで日本からの参加者が集中していたAdaptive Platform(AP)のSystem Test関連の作業部会以外にも、日本からの参加者がちらほらと見受けられるようになったこと、これは大きな前進だと思います。また、新たにPremium Partnerに昇格された企業からの参加者もお見えでした。

 「AUTOSARは不完全、不十分、日本では使いにくい」という声を上げることも重要ですが、批判めいたことを言い続けるだけなら状況はほとんど変化しません。しかし、Architecture、Safety/Security、MethodologyなどのLead WGや、車内通信(IVC)/V2Xなどの各種WGへの参加エキスパートがもっと増えていけば、日本の自動車産業のプレゼンスが向上し、日本固有のユースケースへの考慮もしてもらいやすくなります。そうすれば、徐々にではありますが「使いにくい標準」を「使いやすい標準」に変えていくことができます(あと、小さなことですが、こちらの参加しやすい時間帯に会議を設定、変更してくれるようにもなります、これは、筆者自身の体験です)。

 なお、筆者も、ささやかではありますがお役に立てればと、AUTOSARでの標準化作業(規格やレファレンスコードの開発活動)に参加しようとする方々向けの資料を先日から公開しています(最初はJasPar AUTOSAR標準化WG内のみへの提供でしたが、今はAUTOSAR会員であれば無償でご提供しています)。この資料は筆者の所属企業(イーソル)が2019年から提供しているAUTOSAR関連の有償トレーニングサービス用資料の一部であり、その内容は、標準化作業でのプロセスやチケットシステムなどの使い方だけではなく、文化や常識の違いなどについて、筆者の経験に基づきできるだけ平易にまとめたものです。

 この資料をご希望の方は、以下の筆者の連絡先までお問い合わせください(t-sakurai[at]esol.co.jp、メールの際は[at]は@に置き換え)。なお、ご返信は遅れる可能性がございますことと、ご提供できない場合があることについて、あらかじめご了承ください。

 なお、前述の通り、AUTOSAR会員向け限定のご提供となります。標準化作業に参加可能な会員資格をお持ちの方(Core Partner、Strategic Partner、Premium Partner、Development Partner、Attendee)だけではなく、現在Associate Partnerから標準化作業に参加できるPartner資格への昇格をお考えの方にも提供可能です。

 特にAssociate Partnerの方々は、その資格のままで参加し続けることは、特に知財面のリスクにもつながります(ご関心のある方は筆者まで)。ハードルの高さからAssociate Partnerにとどめておいでだったという方がいらっしゃいましたら、その高いハードルを下げるためのお手伝いはできますので、まずはご相談いただければと思います。

AUTOSARの最新リリース:Adaptive Platform(AP) R19-03

 さて、ようやく予告していた内容に入ります。

 前回は、AUTOSAR Adaptive Platform(AP)のR19-03(2019-03-29)での変化点の解説をすると予告しましたが、その後、「しまった!」と気付きました。

 というのも、Release Overview(参考文献[1])に書かれているように、R19-03は「Revision」であり、前回のR18-10でのさまざまな問題を解消することを目的とした、「Stabilization Release」だからです。

 原則的に新たな機能の追加を意図しておらず、新規Conceptへの追加対応や新規文書の追加などはありません(図1)。

 今回のR19-03の対象は、AP R19-03とFoundation (FO) R1.5.1です。Classic Platform(CP)に関するリリースはありません。

 これまでAUTOSARではリリースの種別をMajor Release、Minor Release、Revisionの3つに分けており、バージョン表記としてRyy-mmの形式を取っているAPでも、この3種類のいずれかの種別に当てはめられます(バージョン表記からでは3種類のどれかは一目では分かりませんが)。

図1 図1 バージョン表記の方式(クリックで拡大)

 皆さまのご興味を引きそうな変更点はあまり多くありませんが、Release Overviewに記載されている変化点と制限事項について、簡単にまとめてみました。

 また、R19-03では各要求事項に{DRAFT}のマークがつきましたが、Release Overviewで「all requirements have the lifecycle status draft.」と書かれているようにもともとdraftであり、このことは前回のリリースR18-10の内容でも同様です。

 まずはアーキテクチャ面から(図2)。

 今回はインタフェース部分の見直しが多く見られます。組み合わせてみたら問題が見つかる、というのはごく一般的なことですので、改訂が少しずつ進められています(実際のところ苦労しているようです)。

図2 図2 APのアーキテクチャ(論理面)(クリックで拡大)

Copyright © ITmedia, Inc. All Rights Reserved.