さて、ゴールについてだいぶ字数を割いてきたが、実際の作業を進める上で必要になるものや役立つものについても触れなければならないだろう。ここでは、必要となり得るもの、役立つ可能性のあるものを示す。ただし、どれが必要でどれが役立つかは、状況や立場、習熟度などによって大きく変わるため、一概に申し上げることはできない。必要に応じてご相談いただきたい。
いわゆるAUTOSAR Authoring Tool(AAT)。筆者が所属するETASの製品であれば「ISOLAR-A」が該当する。Artopからダウンロードしてきたものだけで何とかしようとするのは極めて難しい。また、データ交換形式がXMLを基本としているからといって、テキストエディタやXMLエディタだけで乗り切ろうとするのはあまりにも無理がある。
基本的にツールは、幾つかの種類を用意しておくとよい。評価段階では、その違いを把握することが重要なポイントである※5)。チーム構成などにより、必要なライセンス数や形態も変化する※6)。ツールごとに守備範囲や得意範囲が異なることもある。参考までに、ECUサプライヤ側でAATを使用して行う典型的な作業は以下の通りである。
・ECU Extract編集
たとえファイルが自動車メーカー側から提供される取り決めであったとしても、ECUサプライヤ側で編集が必要になることは少なくない。また実用上は、従来型のデータ形式(DBCなど)をECU Extractに変換するなどの機能が必要になることが多い。
・SW-C定義
この作業は、通常複数人で行う。
・RTE/BSW設定
この作業は1人または少数の人間が行う。また、MemMap設定、Compiler Abstraction設定、SchM周期関数起動設定やCritical Section定義、EcuM callout設定などもあるが、これら必須の作業の全てがAATにより自動化されているわけでは決してない。
AUTOSARを使用しない場合でもECU開発に使用してきたツール類である。
・Build環境
Compiler、Assembler、LinkerやMake環境/統合環境が該当する。Compiler選択においては、スケジュール上の制約から、MCALを起点に考えなければならない場合と、Osを起点に考えなければならない場合がある。また、makefileなどの作成には案外時間がかかるので、あらかじめそのことも考慮しておくべきである。
・デバッグ環境
Debugger(ソフトウェアおよびハードウェア)、Target Board。
・ネットワーク解析ツール
ソフトウェアおよびハードウェア。なお、ソフトウェアに関しては、BUSMASTERのような無償のツールも存在する。
・相手側ECUまたはそれを模擬するもの(ネットワークシミュレーションツールなど)
・MCDツール(必要に応じて)
・Flash書き換えツール(必要に応じて)
・構成管理システム(必要に応じて)
・テキストエディタ
grep機能は必須。可能であれば、grepによる検索と置換を同時に行うことができるとより良い(例:秀丸エディタ)。
・XMLエディタ
XMLレベルでの差分が取れるものが良い(例:XMLspy)。
・Compare Tool
生成されたファイルをフォルダごと比較できること、コメントの差異を無視しコードの差異のみを表示できること、差分を見ながらマージ/編集できること、などが重要なポイントとなる(例:Beyond Compare)。ECUソフトウェアのインテグレーション作業は、BSWなどの設定を変え、生成されるコードや実行時の動作の変化を見て学ぶというのが定石だからである。
・Enterprise Architect(EA)
AUTOSAR規格開発における、標準UMLエディタである。規格として配布されているファイルの一部は、このツールのデータそのものである※7)。
・Process Explorer
例えばコード生成時の動作異常は、Code Generatorやその呼出元のどのレベルに原因があるのかを見つけ出しにくい。そのような場合には、各実行ファイルの依存関係の解析手段を提供する本ツールが役立つ。
・Java Runtime(JRE)
多くのAATがEclipseベースであるため、JREは必須である。また時折、そのバージョンに関する相性の問題も目にする。しかし、セキュリティなどの理由により、使用禁止やバージョン指定がIT管理部門より行われる場合がある。これらの両立が時に困難となるため、事前にそのような場合の対処を協議し社内調整しておくべきである。
・Windows 7の64bit版と大容量メモリ
RTE/BSW設定を進めていくうちに、EcuC(XMLファイル)が巨大になり、メモリ不足になることは少なくない。また実際に、32bit版OSでは、利用できるメモリに上限があって実用的でないことから、32bit版OS対応を打ち切り、今後は64bit版OSにしか対応しないAATも増えてきている。開発中にメモリ不足に陥った時、各種開発ツールを運用しているPCのWindows OSの入れ替え作業をすぐに行えるわけではないし、開発終盤の忙しい時期に作業が止まるのは致命的となり得る。このことから、開発当初から64bit版としておくことを推奨する※8)。なお、開発現場では多くの場合、PCのメモリ容量を8GB以上としているようであるし、32GBとしていることも珍しくはない。
・SSD
大量のXMLを編集する際、ドライブアクセス速度がツールの操作性を大きく左右する。SSDには寿命の問題もあるが、作業性改善には絶大な威力を発揮する。
・外付けの大画面ディスプレイ
ノートPCを使う場合でも、外付けの大画面のディスプレイは必須である。ウィンドウを複数並べて表示しなければならない場面は非常に多く、それができないと作業効率が劇的に低下するからだ。また、ツールのGUI設計によっては、画面サイズが小さいと表示しきれないこともある。
・PC用キーボード/マウス
RTE/BSW設定においては、特にマウス操作回数が相当多くなるため、腱鞘炎は十分に予見可能なリスクであろう※9)。労災や開発効率低下の防止のために、人間工学的な配慮は必要である。また、壊れた時に作業を止めてしまわないように、チーム内に予備を用意してあると安心である。
・電子会議システム
例えば、WebExなど。サポートの効率は、多くの情報をどれだけ効率的に伝達できるかにより大きく左右される。なお、WebExに限ったことではないが、余裕のある時に事前にテストしておくべきだ(自分自身、肝心の本番で動作トラブルが発生し冷や汗をかいたことは、一度や二度ではない)。
※5)発生した何らかのトラブルが、使用しているツールに起因する問題であったとき、代替手段がなければ、改修が済むまでは作業の手は止まってしまいかねないからである。AUTOSAR規格によりある程度の互換性が担保されているデータを他社と交換する場合に、一方の使用するツールのみで発生したトラブルにおいては、ツールの選定責任を理由にスケジュール遅延などの交渉が難しくなることもあるからだ(特に、ECUサプライヤと自動車メーカーの間で、後者側では問題が生じていないような場合)。また、複雑さを隠すアプローチが取られている場合や、手動オーバーライドができないような自動化が行われている場合も同様である。各種交通手段は、徒歩でたどり着ける限界をはるかに超えるところまで連れて行ってくれる。しかし、徒歩でなければ見えないものもあるだろう。
※6)サーバライセンスあるいはフローティングライセンスは、ネットワーク接続ができない場合には利用できないこともある。そのような場合には、出先でも利用できるよう、ノードロックやドングルライセンスが必要となる。
※7)AUTOSAR_MMOD_MetaModel.eapなどが該当する。なお、それらのファイルの編集の際には、EAのメニューバーの「ツール」→「オプション」の「全般」の項目の「JET 4.0を利用」のチェックボックスをオフにする必要がある。
※8)32bit版対応かつ軽量なAATを探し出せば良いというものでもない。状況によっては複数のAATを使い分けなければならないこともある(例:共同開発のパートナーが指定する設定ツールを使用しなければならない場合や、MCALで指定ツールが存在する場合など)。使用するツールは、必ずしも自由に選べるわけではない。
※9)労働安全衛生法 第二十八条の二では、事業者に対するリスクアセスメント義務が規定されている。仮に対象事業者でなくとも、その義務の存在は知っておくべきだろう。なお、法令では片仮名語を使用しない慣例があるため「危険性又は有害性等を調査」と表現されているが、厚生労働省の各種文書では「リスクアセスメント」と表現されている。
(事業者の行うべき調査等)
第二十八条の二 事業者は、厚生労働省令で定めるところにより、建設物、設備、原材料、ガス、蒸気、粉じん等による、又は作業行動その他業務に起因する危険性又は有害性等を調査し、その結果に基づいて、この法律又はこれに基づく命令の規定による措置を講ずるほか、労働者の危険又は健康障害を防止するため必要な措置を講ずるように努めなければならない。ただし、当該調査のうち、化学物質、化学物質を含有する製剤その他の物で労働者の危険又は健康障害を生ずるおそれのあるものに係るもの以外のものについては、製造業その他厚生労働省令で定める業種に属する事業者に限る。
Copyright © ITmedia, Inc. All Rights Reserved.