GAIO CLUB

2022年09月13日

【第8回/最終回】内製ツールの検討

MBDてさぐり奮戦記
こんにちは。
今回は、本奮戦記の最終回として、内製したツールについてその概要を説明いたします。

統合開発環境

下記のような機能を組込み、第4回で説明した統合開発環境を構築しました。

1. MATLAB Simulink(MathWorks社)やTargetLink(dSPACE社)などのライセンス数を有効に活用するため、社内のライセンスサーバから効率よく最小限の時間だけライセンスを取得する機能

2. MathWorks社やdSPACE社が提供しているAPI(Application Programming Interface)を使用し、Simulinkモデル図(以下モデル図と略します)の各ブロックをTargetLink用のブロックへ変換し、変換した各ブロックへプログラム生成に必要な情報を設定してC言語プログラムを生成し、コンパイルリンクをおこなってマイコンに組み込むオブジェクトプログラムを作成する、一連の処理を自動的におこなう機能

3. TargetLinkのブロックへ設定する、C言語プログラムの生成に必要な情報を一括管理するデータベース機能

4. モデル図の記述について、第5回で説明したモデル記述ルールから逸脱した箇所をチェックする、モデルチェック機能

5. 第7回で説明した、モデル図間の差分を抽出する機能やブロックをサーチする機能

6. 第5回で説明した、カスタムブロックを使ったモデル図の作成を支援するカスタムブロックライブラリ機能

7. テスト工程で使用する開発支援ツール用の各種情報ファイルを自動生成する機能

スタック使用量算出ツール

MBD手法を量産開発へ導入する前から、下記のような仕様でプログラム構造上可能性のある、スタック使用量の最大値を算出するツールを運用していましたが、第6回で説明したように、モデル図から生成したC言語プログラムは、従来の感覚より多くのスタック容量を使用するため、本ツールがより重要になりました。

スタック使用量算出ツールの仕様

1. コンパイラからC言語の関数毎に使用されるスタックサイズを収集
2. CasePlayer2(ガイオ・テクノロジー株式会社)の分析結果から、関数間の呼び出し関係の情報を収集
3. 予め設定した各割込の優先順位やエントリー関数名の情報を元に、上記[1][2]からプログラムの構造上可能性のある、スタック使用量の最大値を算出(意味解析はしていません)

尚、上記[1]の情報が読み出せることをコンパイラの選定基準の一つとしています。

カバレッジマスターwinAMS MBTオプション(ガイオ・テクノロジー株式会社)

我々が内製したツールではないのですが、モデル図とプログラム間でのBack to Back一致性検証が国際規格の要件案として審議されていた時期に、ガイオ・テクノロジー株式会社が企画され、我々がユーザの立場でツール開発に参画したツールで、当時は単体のツール“MC-Checker”としてリリースされました。
その後、テストカバレッジ測定などの親和性から”カバレッジマスターwinAMS”(ガイオ・テクノロジー株式会社)のオプションとしてリニューアルされました。

連載の最後にあたって

MBD手法を導入して量産開発したプログラムの生産量は徐々に伸び、2009年度にはハンドコーディングしたC言語プログラムとモデル図から生成したC言語プログラムの生産量が、行数ベースでほぼ等しくなるまでになりました。

ハンドコーディングではいろんな記述方法が可能で、プログラム中に組み込まれる不具合の原因となる記述ミスはさまざまですが、モデル図は書き方が制限され、不具合の原因となる記述ミスはパターン化しやすく、過去の不具合の原因となった記述に類似する箇所を、機械的に検出することが比較的容易でした。

当時、モデル図を仕様書として使用することを計画しましたが、モデル図は自然言語のような曖昧さがなく、正確に仕様を伝えることができるものの、モデル図を正確に理解するためにはSimulinkの言語仕様を習熟する必要があり、仕様をモデル図で表現することについて、さまざまな立場の関係者から理解を得ることはなかなか難しい状況でした。
また、第5回で説明したように、我々の製品のような複雑な仕様をモデル図で記述すると、一般的に広い平面と深い階層構造をもった3次元の空間が必要で、詳細を把握するために適切なビューワーなどの支援環境整備などが、まだまだ必要な状況でした。

いままで、この奮戦記で説明してきたMBD手法のメリット課題を下図にまとめました。長期間にわたり複数の会社が係わる大規模な組織で、マイコン組込製品の量産開発をおこなう立場で直面し経験したことをまとめています。
開発の種類(研究 、制御のプロトタイピングや量産開発等)、単発の開発 or 長期間の継続的な開発、組織の大小などのプロジェクトの内容により、上記のメリットや課題について、その重要度や難易度が変わり、課題に対する適切な対策方法も変わると思います。
MBD手法はあくまで手段でありMBD手法を導入することを主目的にすると、直面する課題に対する対策に迷う場合もあるかもしれません。

これからMBD手法の導入の検討されている技術者の皆さんへ

我々が奮闘した頃に比べ、今はいろいろな情報がWebサイトにあふれ、さまざまなツールやサポートが提供されていますので、MBD手法を導入する目的を明確にし、必要であれば、十分な実務経験を持ち、皆さんの状況を正しく理解して本質的で実際的なアドバイスをしてくれるコンサルタントを選び、サポートを受けながら果敢にチャレンジして頂けたらと思います。

最後までご一読いただきありがとうございました。

この記事を読んだ人はこんなページを読んでいます。

筆者紹介

のんびり田舎暮らしのエンジニア

約40年前に製造業の会社に入社後、リアルタイム制御をおこなうマイコン組込製品の量産開発を35年間担当し、アセンブラやC言語による制御プログラム開発や、MBDを含むソフトウェア開発環境の構築に従事しました。現役時代は理屈の世界で生きてきたので、退職後は感性の世界に憧れ、写真で絵作りをする世界で遊んでいます。

人気のコラム

最新のコラム