機能安全編

株式会社制御システム研究所　森本　賢一

2012.04.23
※記事執筆時は、三菱重工業株式会社　原動機事業本部に在籍

（FPGAの構想設計）
現在の電子機器はFPGAやASICを抜きには語れません。そしてこれらはハードウェアの側面もありますが、ソフトウェアの側面もあります。したがって、構想設計段階ではFPGAのソフトウェアの側面へのサポートも是非考慮していただきたい。

現在のSystem Plannerでも、ポンチ絵としてなら、FPGAの部品の中に、VHDLで記述するであろう機能ブロックを配置することが出来ます。しかしそれはポンチ絵の域を出ません。そこからXilinx社の開発ツールやシミュレーションツールに繋がるわけでもなく、また社内で共通するIPのライブラリにリンクするわけでもありません。
既存のIPを流用するのならば、そのロジック量もわかりますから、できるだけ安いFPGAを選ぶためにも、機能を配置したら必要なロジック量が合計で出てくる、なんてのも構想設計段階で欲しいところです。

FPGAは今後ますます機能やゲート数を増やし、FPGAの内部が一つのハードウェアシステムの様になっていきます。A/Dコンバータや通信のNICが入っているのも当たり前の時代、特定のブロックを使用する制約や、論理ブロックの配置の最適化も必要になるケースが増えてくるものと思えます。このような詳細段階での制約や知見を、構想設計の段階で適切に『見える化』し、これまでお話したようなリスク分析から一貫した要件との結び付けをもって設計プロセスを進めてゆくことは、FPGAの今後の活用において、ますます大切になるのではないかと考えています。

図研さんには是非、いわゆるPCBの範囲だけではなく、ソフトウェアやFPGA内部の論理合成も含めた総合的な構想設計と製品開発の環境を製品化し、日本のものづくりを牽引していただきたいと願う次第です。


（開発ライフサイクル全体／試験・トレーサビリティ）
ハードウェアもソフトウェアもすべての設計が統括できた暁には、是非お願いしたいのが、試験要領や方案と実施結果の管理ツールの機能拡張です。試験はハードウェア単体の試験や、ソフトウェア単体の試験もありますが、最終的なシステムの統合試験までを統括するテスト環境を構築してもらいたい。

特に大掛かりなCADなどは不要です。WordやExcel、おまけに試験項目をデータベースとして扱う仕組みがあれば、システムとしては構築できるでしょう。最初に定義した要件は、すべて試験で確認される必要があります。どの要件が、どの部位に関係し、どんな試験を実施して、結果がどうだったのか、それらをすべてSystem Plannerで管理してもらえれば、試験の抜けや、試験対象のバージョン管理、試験結果による設計の見直しなど、すべてのことが一元管理できます。

現在でも試験をサポートするツールは市販されていますし、上記のソフトウェアの設計支援も含め、おそらく皆様の会社には、それぞれ個別にシステムがあったり独自に連携しているケースも有るかもしれません。私どもの会社もそうです。しかし要件（Requirement）をすべてのフェーズで共有するためには、おのおののツールが独立していたり、または部分的にデータ変換できるという以上に密な連携が必要となるため、人的な負担も大きくなってしまっています。この部分も是非、図研さんにはがんばってもらいたいです。


（変更管理：Change Request）
開発全体のライフサイクルを扱う機能安全では、すべての開発の評価を終えた後は、部品変更や機能拡張、不適合修正のための変更管理を規定することを求めています。
設計の変更のためには、その変更が機能安全にどう影響するのかの分析（Impact Analysis）を実施し、開発ライフサイクル全体の中で修正が掛かるべき図書、その結果やるべき試験などを事前にすべて洗い出し、変更修正のプロセスをスタートさせます。

このような変更管理も、永続的な機能安全製品の維持にはとても大切な活動です。
とても大切な活動ですが、きちんとライフサイクルとして（エビデンスを残して）まわしてゆくことはとても面倒で大変なことです。普通の設計品質としてのＱＭＳ（Quality Management System）の規定をまわすだけならばまだしも、各判断には機能安全としての評価や分析が必要となりますから、作成する必要のある図書もとても多くなります。

このような変更という時間の流れの中で発生するイベントも、開発環境として扱えるようになってもらえれば言うことはありません。是非これも実現して欲しいです。（笑）



最後の最後にいろいろと好き勝手に要望をお話しましたが、System Plannerはそのぐらい可能性の有る、とても潜在能力の高い製品だと思っています。より多くの設計者の声を反映し、他の国にない日本のものづくりのための設計環境として成長してもらうことを楽しみにしています。


（おわりに）
今回後半でお話した『是非実現して欲しい機能』は、IEC-61508に記載が有るものの、このメルマガの連載で触れることが出来なかったテーマでもあります。機能安全規格はまだまだ進化をしており、2010年に発行されたIEC-61508（第２版）でも、多くのページが追加になり議論が深まっています。（深まらずに放置されているものもありますが。）

もしもこのメルマガで興味をもたれた方は、機能安全IEC-61508を手にとって、じっくり読んでいただければと思います。

この連載で紹介した機能安全の様々な手法や考え方が、たとえ安全というものには直接関係しなくても、皆様の製品品質の向上のヒントにすこしでもなることを祈っています。

途中お休みをいただきながらの長期に渡る連載でした。
最後までお付き合いいただいた皆様には、深くお礼申し上げます。

ありがとうございました。

Archive

• 機能安全　～上流で設計すべきもうひとつの品質