AUTOSAR Countdown Calendarは1700記事になりました。ありがとうございました。
AUTOSAR Countdown Calendar 2022
AUTOSAR記事以外に、AUTOSARが目指しているModel Based Development, Auto Code Creation, Auto Testは、どの技術分野共通であり、その背景となる要素について、過去にいいね💚をいただいた記事を参考に掲載させていただいています。お気軽に閲覧のうえ、「いいね💚」を閲覧した記録として押していただけると幸いです。
今週取り上げる資料
Adaptive Platform Demonstrator Release Notes
https://www.autosar.org/fileadmin/standards/adaptive/22-11/AUTOSAR_TR_APDemonstratorReleaseNotes.pdf
https://www.autosar.org
2020年から、AOCが公開になった。2020年はDemonstratorのデモがいくつかあった。2021年にはデモはなかった。2022年12月、WEBの更新とともにAOCの動画の公開URLが消えた。
2020年からDemonstratorは翌年４月に公式配布になっている。
しかし、R20-11のPre-Releaseは公開しても、R21-11. R22-11のURLはリンク切れ。
| Date | Release | Changed by | Description |
|---|---|---|---|
| 2022-11-24 | R22-11 | AUTOSAR Release Management | • R22-11 APD Pre-Release |
| 2022-04-22 | R21-11 | AUTOSAR Release Management | • R21-11 APD Release |
| 2021-11-25 | R21-11 | AUTOSAR Release Management | • R21-11 APD Pre-Release |
| 2021-04-16 | R20-11 | AUTOSAR Release Management | • R20-11 APD Release |
| 2020-11-30 | R20-11 | AUTOSAR Release Management | • R20-11 APD Pre-Release |
| 2019-11-28 | R19-11 | AUTOSAR Release Management | • Release R19-11 |
何がしたいかわかっていない。
たとえば、Demonstrator Design of Functional Cluster Log and Traceは、
3 Usage example
The following minimal sample code demonstrates the usage of the implementation of Log and Trace:
#include "ara/log/logging.h"
#include "ara/log/log_stream.h"
using namespace ara::log;
int main(int argc, char **argv) {
/*
* Explicitly configure the logging framework.
This will be handled by ara:core::Initialize() in future.
Specific work-around for ara-demonstrator-platform.
* ************************************************************
*/
InitLogging(
"TEST",
"This is a test application",
LogLevel::kInfo,
LogMode::kRemote | LogMode::kConsole,
"/tmp/");
Logger& context1 = CreateLogger("CTX1", "A sample context", LogLevel::kInfo
);
context1.LogInfo()
<< (bool) true
<< (uint16_t) 1000 /* uint8_t, uint_32 and uint_64 defined as well
*/
<< (int16_t) -1000 /* int8_t, int_32 and int_64 defined as well */
<< (float) -1.2345 /* double defined as well */
<< HexFormat((uint8_t)0xAB) /* uint_16/32/64 defined as well */
<< BinFormat((uint8_t)0xCD) /* uint_16/32/64 defined as well */
<< "TestString" /* ara::core::StringView defined as well */;
return 0;
説明文の行数があっていない。なんじゃらほい。
AUTOSAR R22-11 資料更新第三段階 進捗
| 日付 | 資料更新 |
|---|---|
| 2022.1.8 | 50 |
| 2022.1.15 | 101 |
| 2022.1.22 | 142 |
| 2022.1.28 | 189 |
| 2022.2.4 | 250 |
AUTOSAR R22-11 マラソン
Release OverView
| 日付 | Do c. | Title | Qiita | 概要 |
|---|---|---|---|---|
| 1/2 | 0 | Classic Platform Release Overview https://www.autosar.org/fileadmin/standards/classic/22-11/AUTOSAR_TR_ClassicPlatformReleaseOverview.pdf | https://qiita.com/kaizen_nagoya/items/80636f4ca7c16501803b | 文書番号/URL追記 |
| 1/13 | 781 | Foundation Release Overview, https://www.autosar.org/fileadmin/standards/foundation/22-11/AUTOSAR_TR_FoundationReleaseOverview.pdf | https://qiita.com/kaizen_nagoya/items/7fcfa4aa0786a38ac3d6 | 強化 |
| 1/21 | 782 | Adaptive Platform Release Overview, https://www.autosar.org/fileadmin/standards/adaptive/22-11/AUTOSAR_TR_AdaptivePlatformReleaseOverview.pdf | https://qiita.com/kaizen_nagoya/items/7f8d6ddacc8573351232 | 統合 |
残念なことがあります。AUTOSARがつけている文書番号をAUTOSARの一覧類で記載しないことです。
規格類のほとんどが文書番号で呼んでいるのには、唯一性を確実にするためという目的があることをAUTOSARもわかっているからつけているはずです。
なぜ一覧に文書番号をつけないのでしょうか。
Requirements on AUTOSAR Features, No.294, CP, AUTOSAR R21-11 obsolateなのになぜR22-11フォルダにファイルがあるのか。
廃止文書を参照しつづける理由
ところで、廃止した文書の番号がわからないでいます。
どういう文書を廃止したのか調べようと思っています。
Requirements on AUTOSAR Features, No.294, CP, AUTOSAR R21-11 obsolateなのになぜR22-11フォルダにファイルがあるのか。
AUTOSAR Abstract Platformへの道（詳細編）
もうすぐ半分に到達するため書き始めました。
<この項は書きかけです。順次追記します。>
主な活動の方向性
各文書に、Abstract Platform中心設計とした場合の追加、変更するとよい事項を記載する。
その際に、現在の文書数は多すぎて、粒度のばらつきが大きい。
ソフトウェアモジュール設計も、再構築することを前提として考え方を示すようにする。
AUTOSAR Classic Platform文書を半分にする方法
AUTOSAR NA(Not Applicable)の構造への反映
資料の方針
新たに文書を起こすだけでなく、ReserchmapのURL変更に伴い、リング切れになっている文書類を、
当初目標だったGithubに改定して転載するための中間置き場としてQiitaを利用する。
例：
踏切の安全分析
AUTOSAR 記事1000までの道
AUTOSAR Abstract Platformへの道 R22-11
作業環境
箱庭プロジェクトなどの動作確認のため、作業環境を整備中。
Raspberry PIの動作は、５月の連休か夏休みになる予定。
今日M2 MacbookAirが届いた。
１年ゲーム断ちして
教材作成
動く教材は、Adaptive PlatformのDemonstratorを動かすことと、
箱庭プロジェクト成果を動かすことを優先する。
AUTOSARの基礎 の 仮説
先週までの報告
AUTOSAR Abstract Platform User Group Weekly Report(2) 2022.1.15
AUTOSAR Abstract Platform User Group Weekly Report(1) 2022.1.8
AUTOSAR Abstract Platform User Group Weekly Report(3) 2022.1.22
AUTOSAR Abstract Platform User Group Weekly Report(4) 2022.1.28
Monthly Report(1) AUTOSAR Abstract Platform User Group 2022.1.29
AUTOSAR
1. 制御のMBD(Model Based Design/Developmemt)
MATLAB/Simulink などの連続模型と、EnterPrise ArchitectなどのUML離散模型とから、系全体を自動生成する。
課題としては、連続系と離散系の連成と、それぞれの道具間の連携。
離散系では安全分析、実時間処理などの対応から、状態遷移(state)図（表）、時系列図(sequence chart)、刻時図(timing chart)が必須。
2. 制御を邪魔しない通信規約CANと、制御を邪魔せずCANを助けるOSEK/VDX OS/COM/NM連携自動生成
AUTOSARではOSを拡張し、COM、NMの一部を仕様変更し、OILではなくARXMLを採用することにした。
Adaptive PlatfomのPOSIX/Ethernetではあたりまえに実現していたRPCをCAN/OSEK/VDX OSで実現しようとしたのがClassic Platformであるとすれば、設計の方向性は全く同じ。
車載EthernetではSwitchingを基本とするためCAN同様の制御の邪魔をしない通信が可能になり、LinuxがOSEK/VDX OS 以上にゼロコピーを実現できれば大丈夫かも。
3. 物理的なECUを作成する前に仮想環境で模擬試験する。
ECUを製造する前に、アプリを作成し試験ができるようにする際に、2002年当時はCPUのシミュレータの作成が課題だった。下記で紹介するAthrillは、一つの解決事例。
4. 実時間処理設計のためにエンジンベンチ、モータベンチで、負荷試験、制御試験を実施し、短時間制御できるように固定小数点と表引きによる高速処理を実現する。
エンジンベンヂ、モータベンチからHILSによる実時間設計を確実にする。
ツールベンダの競争領域とみなされ、AUTOSARではあまり議論を深めていないかもしれない。
Adaptive Platformで実時間処理への対応から、Classic Platformと同じ理論的な取り組みで実現可能であり、ツール類の整備が進む可能性があるかも。
5. CAN/OSEK/VDX OSで、Linux/EthernetのようなRPCを実現し、リソースの再配置を容易にする。
AUTOSARはlinux ethernetでできていたrpcをCAN OSEK/vdx osで実現することが基本設計の一つ。
OEMとSupplierの利害が必ずしも一致していないかもしれない。
実時間処理では事実上使わない機能かもしれない。
通信速度、処理時間、処理空間の兼ね合い。
AUTOSAR Abstrct Platform
Specification of Abstract Platform, AUTOSAR 22-11, XP, No.947
Abstract PlatformとAdaptive Platform、Classic Platformの間は、双方向なやりとりを可能にしようとしている。
Abstract PlatformからOSなし、その他のOSなどとの間は、一方通行を検討しようとしている。しかし、モデル定義を公開すれば、逆方向も可能な道具立は作絵師できるかもしれない。
AUTOSAR Abstract Platfromの考え方は、
2002年にAUTOSARが始まった頃の、上記1,2,3の考え方と基本的な方向性が同じ。
模型(model)を作り、模擬試験(simulation)して、自動生成する。
制御の基本的な手順である。
自動車という分野で実現するための一つの道筋のようで、
すべての制御模型の基本手順である。
抽象的な定義をうまく作り込めば、他の産業分野でも応用が可能な道具立ができることが鍵となるかもしれない。
20年前との違い
AUTOSARが始まった2002年ころと、現在の違いの視点をいくつか記録する。
Matlab/Simulink
MATLAB/Simulinkのソフトウェアライセンスは、製品寿命への対応よりも、
製品そのものの品質と、セキュリティ対応から、新しいソフト対応に傾斜しているかもしれない。
トヨタ自動車、MBDの更なる生産性向上を目指して、MATLABをR2021aへ移行
C/C++
セキュリティ対応のため最新の国際規格を参照する方向に切り替わった。
gcc++
8086系cpuの最適化が進んだことと、色々なCPUのクロスコンパイラをチップベンダが協力し
ARM
AUTOSAR Adaptive Platform Demonstratorでは、Raspberry PI3, 4を使って作成している。量産でもARMの使用率は高くなっているらしい。
open source
adaptive platform dfmonstrator は,ほとんどopensourseからなっている、
Linux
AUTOSAR Adaptive Platformでは、POSEX PSE51という記述がある。
実際にはLinux などのPSE54を使った方が便利な場合はPSE54を使う。
| file/ process | single | multi |
|---|---|---|
| no | 51 | 53 |
| yes | 52 | 54 |
Note that one major change between IEEE Std 1003.13-1998 and
IEEE Std 1003.13-2003 is that PSE53 now requires a file system.
車載LinuxのcovesaなどAUTOSARの外でISOへの入力ができるかもしれない。
車載Ethernet
AUTOSARの外でIEEE、ISO.IECに入力している。
Athrill
ROS対応マイコンシミュレータ athrill 颯爽と登場！
箱庭
箱の中に，様々なモノをみんなの好みで配置して，いろいろ試せる！
AUTOWARE
AUTOWAREの講演をお聞きして、納得感があった。
ちょうど、Athrill, 箱庭のご講演をお聞きした時と同じ感想。
Abstract Platform上で記述した模型が、AUTOWARE上でも動作するとよい。
週報を書く経緯と内容
AUTOSAR Abstract Platform User Group
| 日付 | 人数 |
|---|---|
| 20221127 | 30 |
| 20221218 | 40 |
| 20230110 | 47 |
| 目標 | 52 |
目標52人の根拠は、週報を、毎回、ひとりづつあてに書いていくと、52人で１年が終わる感じ。
週報を書くにあたって、特定の個人に向けて報告を書く形式にさせてください。
なお、この週報は、30点を目指しており、70点分の記載はありません。
３人が別々の方向で直交する30点の記述を持ち寄れば90点になるかもしれません。
百点満点の三十点を目指しなさい。
参考資料
A big wrapping cloth with the miniature garden
AUTOSAR 「完全に理解した」
プログラマの「日報、週報、月報、年報」考。仮説(73)
日報、週報、月報、年報 考 2022
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
文書履歴(document history)
ver. 0.01 初稿 20230204
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.