機能安全認証における世界との距離感（第2回目）
グローバル企業の先行事例から学ぶ機能安全開発への取り組み方

海外企業で活動する専門家たちに事前に書面やビデオ会議によりインタビューを実施し、その回答に基づいて日本側で開催した機能安全規格に関する座談会（海外の専門家たちの回答はテーブル形式で記述）。その内容をまとめた記事の第2回目となる本稿では、HMS、IARシステムズ（以下、IAR）といったグローバル企業における機能安全認証取得の先進的な事例を紹介する。その上で、機能安全認証を取得する日本企業の取り組みに活かせるような具体的なポイントを探る。

【書面やビデオ会議による事前インタビューの参加者】

Alexander Hess氏　HMS Technology Center Ravensburg GmbH、Business Unit Ixxat、Managing Director
Stefan Kraus氏　HMS Technology Center Ravensburg GmbH、Business Unit Ixxat、SafeCom Product Line Director
Stefan Skarin氏　IAR Systems and I.A.R. Systems Group AB CEO

【日本での座談会への参加者】

伊東仁氏　HMSインダストリアルネットワークス　シニアエンジニア
佃和久氏　HMSインダストリアルネットワークス　セールス
山田優氏　IARシステムズ　ストラテジックセールス兼機能安全担当、FSEG事務局

多様化するニーズに適合した機能安全対応（HMSの機能安全製品について）

HMSは、機能安全市場に向けたハードウェア製品とソフトウェア・スタックの両方を用意しています。それらはどのような戦略で売り分けているのでしょうか？

HMS

生産規模が小～中で、必要とする安全アプリケーションがシンプルなユーザーにとっては、機能安全製品をすべて自社開発する余裕はありません。そこでHMSは、簡単に機能安全を組み込める安全入出力（IO）ソリューションとしてT100を開発しました。これによってユーザーは、機能安全関連部の実装と認証取得について細かい事柄に対処することなく、独自の安全製品を開発できるようになりました。 より複雑な安全アプリケーションを必要とするユーザーや、すでに安全ハードウェアを持っているユーザーにとっては、安全通信ソフトウェア・スタックが理想的な製品です。これによってユーザーは、安全通信に関する仕様の理解や実装作業に時間を費やす必要がなくなり、本来のタスクである安全アプリケーションの実装に注力できます。HMSの非安全通信インターフェース「Anybus CompactComシリーズ」に安全通信ソフトウェアを組み合わせることで、ユーザーの安全アプリケーションを様々な産業用イーサネットの安全ネットワークにより簡単につなげられます。

伊東　一言で表現すると、安全通信は必要だが複雑な機能はいらないユーザーにはT100が、複雑な安全機能が必要なユーザーにはソフトウェア・スタックが適しています。両方を用意することで、様々なユーザーに対応するという戦略です。

今後の発展に向けて、どのような戦略を立てていますか？

HMS	HMSは、安全ソフトウェア製品と安全ハードウェア製品の両方を提供するという現在のアプローチを維持します。そして最新の規格適合性テスト（コンフォーマンス・テスト）に常に合格できるよう、既存製品のメンテナンスを続けます。さらに、当社のT100という絶好のプラットフォームを活用して、ユーザーからのさらに高度な要求にも応えられるよう、より高機能な製品を開発しています。

顧客ニーズに合わせて幅広く機能安全対応をした例（IARの機能安全製品について）

IARは機能安全製品としてツール認定済みのコンパイラを提供していますが、なぜIARは、機能安全版コンパイラのツール認定を受ける際、「IEC 61508」や「ISO 26262」（車載機器）、「IEC 62304」（医療機器）、「EN 50128/EN 50657」（鉄道）、「EC 60730」（家電機器）、「ISO 13849/IEC 62061」（機械制御）、「IEC 61511」（プロセス制御）、「ISO 25119」（農業機器）などの規格を取得したのでしょうか？

IAR	基本的には、カスタマからのリクエストです。IARがどの規格に準拠するかを決めているわけではなく、ユーザーの要望に対処するかたちで規格を取得しています。

競合他社に比べて早い段階に機能安全版コンパイラを製品化できた理由は何ですか？

IAR	IARは、世界全体で約4万6000社の企業との取引があります。その中の大手グローバル企業から機能安全版コンパイラの製品化のリクエストがありました。それに応えるかたちで製品化することで、非常に早いタイミングでの市場投入が可能になりました。 それ以前は、機能安全版コンパイラを提供する場合、ユーザーごとに個別契約を結んでいました。つまり、カスタム契約やエンタープライズ契約です。しかし大手グローバル企業のリクエストをキッカケに、機能安全版コンパイラをパッケージ製品として発売したことで様々なユーザーが機能安全版コンパイラを安価に入手できるようになりました。

大手グローバル企業のリクエストとはどういったものだったのですか？

IAR

固定バージョンでサポートしてほしいという要望でした。コンパイラの保守契約では、不具合が見つかると最新版で修正します。バージョン1で見つかった不具合は、バージョン2以降で修正する。つまり、ユーザーが不具合を回避するには、バージョンアップするしか方法がなかったわけです。しかしコンパイラはバージョン変更すると、オブジェクト動作などが変わってしまい、認証においてはテストのやりなおしなど大きな手戻が発生します。また、組込み製品では製品サイクルが10-20年といったケースも珍しくないので、その間にコンパイラを頻繁にバージョンアップしないといけないとなると、認証を取り直す工数やメンテナンス工数も膨大になります。 このため特定のバージョンを固定してメンテナンスしていくやり方が固定バージョンです。機能安全の開発においては利用ツールの妥当性を証明する「ツール認定」という考え方がありますが、特に製品の実行コードに直接影響を与えるコンパイラは最も要求レベルが高いツールに位置しています。 現在IARでは、幅広い規格向けにツール認定を取得したコンパイラを機能安全版として提供しており、固定バージョンサポートを提供しています。これにより昔は苦労したツール認定に関する悩み事の多くはリーズナブルな価格で解決できるようになりました。

HMS：初めての機能安全開発、社内プロセス確立と仕様変更対応に苦労

最初の機能安全製品の開発で苦労した点などを教えて下さい。

HMS

当社の機能安全製品は、「Ixxat」というブランドで市場に投入しています。その最初の製品の開発には、今から16年前の2005年に着手しました。開発の初期段階での最大の課題は、機能安全製品を開発するための仕組み作りでした。例えば、社内の開発プロセスの整備や、開発ツールの準備などです。機能安全製品の開発では、不具合の発生を極力避けるために、使用実績のある標準的な開発プロセスを使うことが必須なうえに、開発プロセスと成果物の両方が「DIN EN 61508」「IEC 62061」「IEC 13849」といった機能安全関連の標準規格を満たす必要があったからです。 この開発プロジェクトは、あるユーザーからの開発委託によってスタートを切りました。しかし、そのユーザーは機能安全製品の開発は初めて。このため、開発の途中で製品仕様が何度も変更されました。機能安全製品の開発では、あらゆる要求事項と変更について完全なトレーサビリティを維持しなければなりません。そのため要求事項が何度も変更されるという状況は非常に致命的で、最終的に多くの工数がかかってしまいました。 結果的に成功を収められた最大の要因は、HMSの開発メンバーとプロジェクト・マネージャーの高い専門性と、改善を絶えず続けていく姿勢が挙げられます。さらに、開発の初期段階から社外のコンサルタントと契約してサポートを得たこと、第三者認証機関のテュフラインランドと緊密な関係を構築したことも成功要因の1つといえるでしょう。

2005年の時点ですでに機能安全のコンサルタントが存在していたのですか？さらに認証機関は、様々な相談に応じてくれるものなのでしょうか？

伊東　はい、そのようです。また認証機関についてですが、確かに日本では「認証機関は質問や相談に対応してくれない」という話をよく聞きます。しかし、ドイツには認証機関と緊密な関係を構築する下地があったようです。

山田　欧州では、機能安全業界における人の流動性が高いようです。さらにドイツを訪れると分かるのですが、TUVは街中に看板やロゴをたくさん掲げており、主要な都市にはオフィスを構えています。それだけユーザーとの距離が近いわけです。加えて、メーカーで機能安全に携わったエンジニアがTUVに転職したり、その逆もあったりします。機能安全は、「機能安全村」と呼ばれるぐらい狭い業界ですので、その中で知り合ったエンジニアがいれば、比較的簡単に緊密な関係を構築できるのだと思います。

一方、日本はTUVの本社があるドイツとの距離が遠いうえに、機能安全認証に知見のある人材が認証機関や企業外に出て転々とするような人材の流動性はまだ低い。このため、機能安全に関する情報が流通したり、引き出されたりすることが難しいのでしょう。

HMS：最初の機能安全製品の開発期間は約3年

HMSでは、機能安全認証を最初に取得する際、どの程度の時間と工数をかけましたか？

HMS	2005年に着手した最初のプロジェクトは、機能安全向けソフトウェアが開発の対象でした。開発は、プロジェクト・マネージャーが1名、デベロッパー/テスターが最大3名という体制で取り組み、仕様策定から製品リリースまで約3年を要しました。 具体的には、安全コンセプトと要求仕様の策定に約6人月の工数、コーディングには12人月以上の工数、コードレビューやユニットテスト、システムテストには24人月以上の工数がかかりました。このほか、仕様変更要求への対応や、開発やテストの過程で発生した問題への対応のために、最終的には18人月の工数が計画外で投入されました。

認証機関とはどのように関係性を築いたのでしょうか？

HMS

機能安全製品の開発はコンセプト・フェーズから始まります。このコンセプト・フェーズから第三者認証機関を巻き込んで、なるべく早い段階でフィードバックを得られるようにすることが成功の秘訣です。これによってプロジェクトの最初の段階で関係者全員の技術的レベルを合わせられます。そして、このプロジェクトで開発するべきものは何か、当社内で開発をどのように実行すべきかについて、認証機関と観点を一致させることが重要です。さらに、我々は常に認証機関と非常にオープンかつ協力的な姿勢で関係を構築します。そうすることで、認証機関と同じレベルで議論することができ、認証の過程での説明に費やす労力をより少なくすることができます。

Ixxatブランドの機能安全製品に対する日本市場の反応はどうでしょうか？

HMS	我々の製品は日本のマーケットにおいて大きな成功を収めており、そのことからも、日本のユーザーは満足してくれていると見ています。日本における当社のユーザーの多くは、安全通信ソフトウェア・スタックを使っています。すでに機能安全開発の経験があるユーザーが多いため、当社の製品に対する期待が非常に大きいですが、品質面でも使い勝手の面でもその期待に応えられていると考えています。

日本の事情に合わせ込むと、日本企業は認証機関とどのような関係を構築すべきなのでしょう？

伊東　企業と第三者認証機関との距離感は、ドイツと日本で大きく異なります。そのため、HMSの事例は参考にならないかもしれません。しかし日本企業は、距離感があるがゆえに、第三者認証機関を絶対視し過ぎている面もあるかもしれません。「あまり深く話すと審査に支障が出るのでは」と心配して情報を開示しないのではなく、もっとオープンに議論していく。こうした姿勢は、日本企業の参考になると思います。

IAR：意外に大変なツール認定

機能安全認証では、利用ツールの妥当性証明を求めるツール認定があります。IARは既に機能安全版コンパイラでツール認定を取得済みですが、そのために費やした工数や時間はどの程度ですか？さらに取得時の苦労話があれば教えて下さい。

IAR	工数や時間などの細かな数字を公表できません。ただ言えることは、機能安全版コンパイラのツール認定を業界に先駆けて取得したので、ノウハウや実績をかなり蓄積できています。そのためIARでは、プロセッサ・コアごとに機能安全版コンパイラを用意しているのですが、新しいプロセッサ・コアに対応した機能安全版コンパイラのツール認定に費やす工数を劇的に削減できています。

最初のツール認定を取得する際は、どの程度苦労したのでしょうか。

IAR	機能安全版コンパイラを最初に製品化する際は、非常に多くのコストを費やしました。しかし一度、コストを掛けてしまえば、アップグレードではあまり多くのコストは掛かりません。どちらかといえば、現時点では、固定バージョンのサポートに時間がかかっています。

ツール認定は従来の開発にはない作業項目となりますが、注意点はありますか？

機能安全認証においてはツール認定のように「従来の開発にはない作業工数で、地味で楽そうにみえるが実はすごい大変」といった落とし穴が多々存在します。ツール認定であれば機能安全適合をうたっているツールを活用するなど、きちんとしたツール、ベンダ、知見者の意見を借りることが機能安全対応のなによりの近道ではないでしょうか。

マネージメント向け個別相談会（無償）の申し込み

1〜1.5時間程度で機能安全認証の工数、難易度、世界観をできるだけ具体的にお伝えします。
御社の課題にあわせてFS認証のエキスパートへQAが可能ですので、経営判断や次のステップに進む材料を得ることができます。

今回の座談会参加企業