【第4回】開発環境の構築

開発環境を構築するにあたり下記のような目標を決めて検討を進めました。

1. 長期間使用できる環境を目指し、業界のトレンドを見極めてデファクトとなる商用ツールを採用
2. 自動化、機械化を目指して開発効率を向上させる環境
3. 最小限の習熟工数（ツール操作を習得するのに必要な工数）で使用できる環境
4. 導入コストを許容範囲内にとどめ、購入したツールのライセンス管理が簡単な環境

第1回で説明したように当時（1999年頃）、

・業界のトレンドとして、MATLAB Simulinkはすでに制御系設計支援ツールとしてデファクト
・Simulinkモデル図（以下モデル図と略します）からC言語プログラムを生成するツールが実用化
・ MATLABを外部の開発環境から制御するAPI（Application Programming Interface）が利用可能
・社内でMATLAB関連のライセンスを管理するサーバーを構築可能

の状況で、量産開発のプラットフォームとして十分に目標を達していたので、Simulinkでモデルを設計することを前提に開発環境の構築を目指しました。

尚、これも第1回で説明しましたが、MATLAB Stateflow (MathWorks社）については、プロジェクトが対象とした機種では当時必須ではなかったことから、将来導入することを前提としつつ今後の検討項目としました。

MBD開発環境において、MATLABとともに根幹となるツールとして、モデル図からC言語プログラムを生成するACG（Automatic Code Generation）ツールがあります。

量産開発へMBD手法を導入するにあたり、十分ノウハウを積むまではMBD手法で開発しACGツールで自動生成したC言語プログラムについても、ソースプログラムレビュー（インスペクション）で検証する必要があると考えていました。また、開発中に制御上で見つかった問題の原因を究明するためC言語プログラムを調査する場合があるので、生成したC言語プログラムの可読性は、我々にとって非常に重要な要素でした。
そのため、ACGツールを選定する基準として、上記構築目標と、第3回で説明した固定小数点演算処理への対応に加え、ACGツールが生成したC言語プログラムの可読性を重視しました。

当時（1999年頃）、上記構築目標で選別してゆくと、最終的にMathWorks社製の純正ツールとTargetLinkが候補に残りました。

両者が生成したC言語プログラムの可読性を比較検討したところ、当時は可読性について大きな差があり、TargetLinkが生成するC言語プログラムは、変数名としてモデル図で定義した変数名をそのまま使用し、モデル図に記述した論理がストレートにC言語プログラムへ変換され、処理に関する詳細なコメントが記述されるなど、可読性に優れていました。また、当時TargetLinkのほうが固定小数点演算処理への対応も優れていました。

純正ツールの方が、より最適化したC言語プログラムが生成されてオブジェクトプログラムのサイズや実行時間が短くなる傾向にあり、MATLABの最新版への対応が早いと思われるなど多くのメリットがあったものの、可読性と固定小数点演算処理対応を重視してTargetLinkを採用することにしました。

厳しい納期のもと、正しいプログラムを開発するため懸命に努力を重ねている現場の技術者にとって、使っている開発環境が少しでも変わるのはとても嫌なことです。

開発環境の使い方が分からず、悩んだりすることが頻発し時間がかかると現場は混乱するため、上記開発環境の構築目標[3]を満たすべく構築し、運用するなかで見つかった問題点をリストアップし、定期的に、改善すべき項目を協議し改良する活動を続けています。

総合開発環境では、技術者の習熟工数を最小限にして作業モレなどのケアレスミスを防止するため、例えば下記[1]から[5]のような開発現場で頻繁におこなわれる作業を一つの操作で一括して実行するようにしました。

1. 作成したモデル図について、モデル記述ルール（第5回で説明予定）との整合性をチェック
2. ライセンスサーバからの必要なライセンスを取得して、MATLABやTargetLinkを起動
3. モデル図からC言語プログラムを生成してコンパイルやアセンブルを実行
4. 他のハンドコードしたプログラムから生成したオブジェクトプログラムとともにリンクし、マイコンで実行可能なオブジェクトプログラムを作成
5. テスト工程で使用する開発支援ツール用の各種情報ファイルを作成

次回は、モデル図記述手法の検討について説明いたします。
最後まで、お読みいただきありがとうございました。