AUTOSARの“AR”はアーキテクチャに由来、アーキテクチャ設計にどう使うのか：AUTOSARを使いこなす（40）（2/4 ページ）

車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載第40回は、AUTOSARの最後の2文字“AR”を意味するアーキテクチャと、アーキテクチャ設計におけるAUTOSAR活用について考えてみる。

[櫻井剛，MONOist]

アーキテクチャ設計って何？

　さて、AUTOSARは「AUTomotive Open System Architecture」の略です。

　つまり、最後の2文字の“AR”は「アーキテクチャ：architecture」に由来しています。

　ところで、「アーキテクチャ設計」って、どんなことを行うのでしょうか？

　「何を当たり前のことを」と思われた方もいらっしゃると思いますが、ここでは、学生さんに説明するくらいのつもりで、Automotive SPICE 4.0を基に、おさらいしてみましょう。

　アーキテクチャ設計（システムレベル：SYS.3、ソフトウェアレベル：SWE.2）では、Base Practice（BP）として、以下を提示しています（図3）。

• 静的側面を定義する（BP1、インタフェース定義を含む）
• 動的側面を定義する（BP2）
• アーキテクチャ分析を行う（BP3）

図3　アーキテクチャ設計（Automotive SPICE観点）［クリックで拡大］

　静的／動的側面の定義については、実際には、以下の2パターンや、その組み合わせになるでしょう。

• a）“動的→静的”：まず「実現シナリオ」（動的振る舞い）を描いてから、その切れ目のよいところで切り分け、「それを実現してくれる人、組織、システム構成要素（部品）、道具などの『アクター』に割り当て、アクター間のつながり（人や組織でのコミュニケーション、システム構成要素間インタフェースと接続）」（静的構造）を構築する
• b）“静的→動的”：まず「実現に寄与してくれるアクターとそのつながり」（静的構造）での「それぞれが果たす役割」を定義したり、あるいは既存のものに対する理解を利用したりして、「実現シナリオ」（動的振る舞い）を構築する

　さて、その次は「アーキテクチャ分析」です。Automotive SPICEを読んだ方、「これはなんだ？」と困惑した方も少なくないでしょう。

　静的／動的側面の定義を行った後の「できたなり」の状態で、例えば、「ある振る舞いの開始条件成立（トリガー）からその振る舞いの完了までの所要時間（応答時間）」に着目したとしましょう。

　そうすると、その時間長が想定や制約（要件の一種）よりも大きく、それではシステムが果たすべき役割に支障がある（要件の達成を阻害する）ということであれば、静的／動的側面の定義内容（構造や振る舞いの設計）を見直し／変更することで、時間長が要件を満たすようにしていくでしょう^※1）。

　もちろん、実はその時間長がどのくらいまでなら許容できるのかをそもそも検討していなかったとしたら、それを要件として追加することになるでしょう。

※1）最初からそんなタイミング制約を満たせるように設計するべきだ、とおっしゃる方もいらっしゃると思います。まず、Automotive SPICEのBPの番号は、時系列の指定ではありませんので、タイミング制約を満たせるように設計できるなら、それで構わないでしょう。特に、慣れ親しんだ既知のものの場合、頭の中に「開発活動と開発対象のシミュレーター」がインストールされているようなものですから、それが自然にできてしまうと思います。ただ、頭の中で大丈夫だと思っていても、実際には勘違いしていたなんてこともあるでしょうから、きちんと検証のための分析を行い、その結果の記録を残すことがもちろん必要です。

　しかし、新規に作成したり未知のものを設計したりするのであれば、まずは作ってみて、その「できたなり」を見ることになるでしょう。

　また、「人に危害を及ぼさないか」ということに着目したとしたら、それはいわゆる安全面のリスクアセスメント（ISO 26262でのHazard Analysis and Risk Assessment［HARA］を含む）になります。当然安全方策を適用していくことになります。

　もちろん、リスクはさまざまなものがあります。

　先に登場した「所要時間」でのタイミング違反は人による誤操作リスクにもつながりますし^※2）、そのタイミング違反が処理性能不足によるものだったら下手をするとマイコン／プロセッサの選定からやり直しになるかもしれません。メモリスタックなどの「リソース不足」に後から気付いた時も同様で、大きな手戻りのリスク（プロジェクト進行スケジュールや納期面のリスク）になります。

　さらには、「切り分け、小分け、ブレークダウン」するということは、後に「組み合わせ、統合、インテグレーション」が行われるということですので、組み合わせによる創発的な悪影響も生じてしまうかもしれません。

　実は、いわゆる「品質を作りこむ」ということに相当するのがこの「アーキテクチャ分析」であると言ってよいでしょう。

　静的／動的側面の定義を行った後の「できたなり」の状態に対して、そのシステムのコンテキストや要件を踏まえると重要となるさまざまな観点（手戻りにつながりかねないリソース不足や、各種タイミング特性、安全性など^※3）に着目し、各観点で許容できるかどうかを分析／評価し、許容できなければ許容できるように手を入れていく、ということになります。

　もちろん、リスクには、ネガティブな要因だけではなく、ポジティブな要因もあるかもしれません。

※2）例えば、トグル操作形式のボタンによってシステムのある機能をオフ→オンさせようとするとき、ある程度の時間内にシステムの応答がないと、人は再度操作してしまうでしょう。でも、反応が遅れるものの初回／再度の操作のどちらもシステムが受け付けるとしたら、オフ→オン→オフの動作となりますので、システムの設計者の立場では「誤操作」、操作者の立場では「意図せぬ応答」となってしまいます。

※3）より一般化して「リスク全般」だと考えるなら、製造／組み立ての誤差とばらつきなどもここに含めることができるでしょう。