2.開発手法改善

国際化に対応できる開発環境の構築に向けて!~IEC61508 / ISO26262などの機能安全規格などの対応を見据えて~

背景

現在、国際化が進んでいます。自動制御の開発の手法においても、その問題が深刻になりつつあります。

WTO/TBT(貿易の技術的障害に関する協定)など技術的な非関税障壁撤廃へ

 非関税障壁撤廃のために、規格の国際化が進んでいます。国際化される非関税障壁の中に任意規格(JIS)も含まれています。つまり、国際規格(ISOなど)への適用が必要となります。

 また、受発注の方法も非関税障壁となりえます。日本的な元受⇔下請け関係に基づく受発注も、非関税障壁となりえます。正しい要求仕様とそれに対する設計仕様の提示が求められております。

国内規格(JIS)⇒国際規格(ISO, IEC, etc)
従来のJIS規格は事細かく「どのようにしたら良いか」を記載してあります。ある意味で大変親切な規格と言えます。今までは、この規格を準拠することで、製品の設計・製作が問題無く進んでいました。しかし、ISOなどの国際規格は少々趣が異なります。ISOなどにも当然のように「どのようにしたら良いか」を記載してあります。そして、多くの場合には選択的に提示されています。ここで、問題が発生します。「どの方法を選択したら良いのか?」が決められなくなります。ISOなどは「思想」を重視した規格です。その根本の「思想」を理解しないと、「どの方法を選択したら良いのか?」を決めることができなくなり、一番時間とお金がかかる方法を選択することになります。
国際発注・受注
当然のように非関税障壁の撤廃には、国際調達が必要になります。製品を販売しようとして、市場に入ってきた外国企業を排除することはできません。でも、「いう通りに作ってくれたら良いよ。」という考えかたは通じません。「どのような物を作ってほしいのか。」を要求としてちゃんとまとめなければいけません。後で発生した問題の対応費用が請求される事もあり得ます。海外企業に部品を販売する場合も、同じように発注元の要求がちゃんとまとめられているかに注意しないと、余分な開発経費が必要となります。発注受注に関しても国際規格への準拠が必要となっています。
利用者に対する説明責任
国際的に利用者に対する説明責任(インフォームドコンセント)が重要になってきています。利用者とは、発注元や製品利用者になります。しっかりと説明責任を果たせる開発を行わないと、PL訴訟などで問題となる場合が発生する可能性があります。 この方法に関しても国際規格への準拠が必要となっています。

課題

上記のような国際規格に準拠した開発を行うためには、以下のような課題があります。

要求をまとめる
今までのように、「こんな感じで作って!」では通用しません。受注者が問題無く作成できるものでなければいけません。
要求に適合した設計を行う
「要求をどのように実現するか」を決めるのが設計です。すべての機能をちゃんと定義しないと、後から機能を追加することになり、得てして「後から見てもわからないシステム」になってしまいます。
設計に沿って要素を設計・製造して統合する
設計通りに製造するだけですが、得てして製作時に小問題を修正しただけのつもりで、他の要素に影響を与えて不具合に発展する場合があります。小さな修正を行うことは問題がありませんが、不具合を発生させない修正方法が必要です。
決めた製品ができたか調べる
設計通りにできているかの確認です。設計者が確認方法を決めていることがよくあります。仕様書を確認する意味も含めて、設計者以外が確認方法を決めることが理想です。しかしながら、設計者と同等程度な技術レベルの知識が必要となるため、人的に難しい問題があります。
製品に問題がないか調べる
すべて設計通りにできていても、実際の製品に問題がある場合があります。設計者が十分に考えていたとしても、人間ですから見落としはあります。これも設計者以外が確認方法を決めることが理想です。しかしながら、設計者と同等程度な技術レベルの知識が必要となるため、人的に難しい問題があります。
製品の安全性を説明する
今までは、顧客の信頼を失わないために社内で努力してきた問題であり、外部に表明する必要性もありませんでした。しかし、専門家ではない一般人に説明することは不可能に近い行為です。このためには、専門技術を保有した第三者による検証が必要になります。

対策(対応できること)

1.要求フェーズ

要求の定義

現代の自動制御のシステムは、他のシステムとネットワークで接続されて協調して動作するものがほとんどです。自システムのみでなく、他のシステムとの関係性についての要求をまとめることが重要となります。
多くの重大危険事象が他システムとの連携の調整不足から発生しています。 また、システム内の要素の要求においても、他の要素との関係性を十分にまとめることが重要です。危険事象の多くは、個々の要素は設計通りにできているのに接続部分の要求が十分でなく発生しています。

要件定義・機能分解

 要求を機能に振り分ける作業になります。機能をどのように記載するかが問題となってきます。記載するには準形式手法のUMLまたはSysMLが有効になります。この言語を用いることにより、ブロックへの割り当て機能と機能ブロック間の通信データが明確になります。
AUTOSARのVFB(Virtual Function Bus)にあるように、機能ブロックに割り当てる機能を明確にし、通信データをしっかりと決定することにより、各ブロックの再利用が容易になります。また、統合化したECUを検討する際にも、検討が容易になります。このステップをしっかり行うかどうかで、後のハザード及びセキュリティ分析の出来に影響いたします。

ハザード・セキュリティ分析

 機能分解が完了したところで、ハザード及びセキュリティー分析を実施します。セキュリティーの分析においては、改ざん等の行為が原因となるハザードが発生する場合も含めて検討します。
ハザードと情報漏れを危険事象として分析を実施し、危険事象の発生する条件と原因を明らかにします。
分析方法としては、以下の方法が用いられます。
a. ガイドワードで分析する方法 —– HAZOP Stamp/STPA など
b. 各部の故障で分析する方法 —– FMEA/FTA など

安全方針の決定

 ハザード及びセキュリティー分析によって明らかになった危険事象の発生する条件と原因をもとに、どのように危険事象を防ぐかの方針を決定します。この方針は要求の形であることが望ましいです。
多くの場合、実際の設計経験がある人間は「入力に逆流防止ダイオードを設置のこと」のように具体的な対策を記載しがちです。たぶん多くの場合にその指示は正しいものでしょう。けれども、他の方法の方が良い場合があります。下流の設計者を制約しないように要求の形にしましょう。また、具体的に対策を記載するということは、対策に対して責任を持つことである点に注意が必要です。

要求仕様の作成

 可能であれば、準形式手法(UML, SysMLなど)で記載し仕様とGSNなどで記載した安全方針を、そのまま渡す方法が良い方法と言えます。
しかしながら、一般的には文書での作成は必要となります。文書での作成の場合には、今までの決定事項との齟齬が発生しないことが重要です。今まで検討してきた項目が、この文書であいまいになってしまうことがあり得ます。

2.システム設計フェーズ

システム仕様をまとめるまでに実施する項目及び当事務所で対応可能なサービス

要求仕様の分解

 要求仕様書を元に機能分解を実施します。要求仕様作成者から準形式手法(UML, SysMLなど)で作成されたものが提供されている場合には必要はありません。
作成したものを要求仕様作成者と調整し、要求仕様が実現できるものになっているか確認します。
この結果、要求仕様作成者の考えた機能分解と同じものになった場合には問題はありません。
しかしながら、コストや性能などの問題から要求仕様作成者が考えたものと異なるものとなった場合には、要求仕様作成者は、その機能展開結果をもとに、ハザード・セキュリティ分析から再実施しなければなりません。
ここで、再実施を行わないで開発を続けると、後工程で問題が発生する可能性が高くなります。

機能分解結果への安全方針の展開

 まず、安全方針をどのような機能で実現するかを検討します。検討結果に従って機能ブロックにその機能を追加します。この結果、上記の機能分解で分けた機能ブロックに安全のために機能が記載される形になります。
この結果については、要求仕様作成者と調整をおこない、問題がなければ「安全方針の管理」(ex. Excel,PLM, GSN等)に記録されます。

機能ブロックの詳細化

 上記で作成した安全方針を展開した機能ブロックを展開していきます。展開するレベルは、機械・電気回路・ソフトウェアに分けられるレベルです。たとえば「回転数を一定にする」との機能であれば、
「回転数計測」⇒「回転数制御」
となります。これを機械で実現すれば「ガバナ」になり、電子制御なら「レゾルバ」・「A/D変換」・「PID」になります。ブロックに割り当てられた機能を勘案しながら分解を行うことになります。この詳細化のやり方でどのような制御方法を用いるかが決まってしまう場合もありますので、十分に検討が必要です。
なお、この際に入出力の定義が重要となります。ブロックの定義は「機能」・「入力」・「出力」の3項目は必ず定義してください。
この機能ブロックの詳細化において、過去の信頼性の高いシステムの利用を考えることも重要です。もし、過去の信頼性が高いシステムの一部を利用する場合には、どこが異なっているかを明確にしておく必要があります。

ハザード・セキュリティ分析

 機能ブロックの詳細化が完了したところで、再度ハザード及びセキュリティー分析を実施します。セキュリティーの分析においては、改ざん等の行為が原因となるハザードが発生する場合も含めて検討します。ハザードと情報漏れを危険事象として分析を実施し、危険事象の発生する条件と原因を明らかにします。
分析方法としては、以下の方法が用いられます。
a. ガイドワードで分析する方法
HAZOP Stamp/STPA など
b. 各部の故障で分析する方法
FMEA FTA など

危険事象の軽減措置の決定

 ハザード及びセキュリティー分析によって明らかになった危険事象の発生する条件と原因をもとに、どのように危険事象を防ぐかの対策を策定します。この方針は各詳細ブロックに機能を要求する形であることが望ましいです。
危険事象の軽減措置の決定後、危険事象の軽減措置に対して実施状況をトレースする必要があります。ここにおいてもexcel, PLM,GSN(Goal Structuring Notation)などでとっていきます。また、要求仕様作成者は、この危険事象軽減措置のトレースと自身の安全方針の実施状況を示す資料とを関係づけることにより、安全に対しての説明力が向上します。
実現方法の決定(機械/電気電子回路/ソフトウェアの選択)
 ここまで設計を進めてくると、ほとんどの詳細化された機能ブロックは、どのような方法で実現するかが決定されてしまいます。まだ、決定されていないブロックに対して実現方法を決定します。
各詳細ブロックを「機械で実現するのか」、「電気電子回路で実現するのか」、「ソフトウェアで実現するのか」に割り当てます。
システム設計仕様書の作成
 ここでも同様に、可能であれば準形式手法(UML, SysMLなど)で記載し仕様とGSNなどで記載した軽減措置をそのまま渡す方法が良い方法と言えます。
しかしながら、一般的には文書での作成は必要となります。文書での作成の場合には、今までの決定事項との齟齬が発生しないことが重要です。今まで検討してきた項目が、この文書であいまいになってしまうことがあり得ます。

3.要素設計・製作フェーズ

要素設計仕様をまとめて要素を試作するまでに実施する項目及び当事務所で対応可能なサービス

システム設計仕様書の機能分解
 システム設計仕様書を元に機能分解を実施します。システム設計者から準形式手法(UML, SysMLなど)で作成されたものが提供されている場合には必要はありません。
作成したものをシステム設計者と調整し、システム設計仕様が実現できるものになっているか確認します。この結果、システム設計者の考えた機能分解と同じものになった場合には問題はありません。しかしながら、コストや性能などの問題からシステム設計者が考えたものと異なるものとなった場合には、システム設計者は、その機能展開結果をもとに、ハザード・セキュリティ分析から再実施しなければなりません。ここで、再実施を行わないで開発を続けると、後工程で問題が発生する可能性が高くなります。
ハザード・セキュリティ分析
ハザード・セキュリティー分析
 1機能-1ブロック化が完了したところで、再度ハザード及びセキュリティー分析を実施します。セキュリティーの分析においては、改ざん等の行為が原因となるハザードが発生する場合も含めて検討します。ハザードと情報漏れを危険事象として分析を実施し、危険事象の発生する条件と原因を明らかにします。
ハードウェアの場合にはほぼ設計は完了しているので、FMEAによって部品故障が発生した場合の分析が有効です。また、ソフトウェアに対しては、異常値が入力した場合をFMEAで分析することが有効となります。
また、危険事象の発生確率を計算するためにFTA分析が有効となります。
その結果、システム設計フェーズレベルでの危険事象(システム設計仕様作成時の機能ブロックで閉じない危険事象)が見つかった場合には、システム設計者(場合によっては要求仕様作成者)と調整し、安全対策をやり直します。
危険事象の軽減措置の決定
 ハザード及びセキュリティー分析によって明らかになった危険事象の発生する条件と原因をもとに、危険事象の低減対策を策定します。そのうえで、対策を盛り込んで機能ブロックの再詳細化から実行します。
危険事象の軽減措置の決定後、危険事象の軽減措置に対して実施状況をトレースする必要があります。ここにおいてもexcel, PLM,GSN(Goal Structuring Notation)などでとっていきます。また、要求仕様作成者やシステム設計者は、この危険事象軽減措置のトレースと自身の安全方針の実施状況を示す資料とを関係づけることにより、安全に対しての説明力が向上します。
要素設計仕様書の作成
 ここでも同様に、可能であれば準形式手法(UML, SysMLなど)で記載し仕様とGSNなどで記載した仕様書が、再利用を考慮すると、望ましいといえます。文書で作成する際には、今までの決定事項と齟齬が発生しないように作成します。
機能ブロックの制作
 要素設計書に即して、機能ブロックごとに試作していきます。また、要素設計仕様書に記載されている通りに製作されているかの試験を実施して、その試験結果と製作品のセットで製品となります。
段階的に試験を実施しながら、機能ブロックを組み上げることにより、システム設計レベルで規定した機能ブロックまで組み上げます。最終的に機能ブロックの試験を実施して終わります。

4.統合・製品試験フェーズ

システム統合試験及び製品試験において実施する項目及び当事務所で対応可能なサービス

統合試験(要素設計仕様書レベル)
 要素設計仕様書を元に試験を実施します。
 要素設計仕様書に規定している通りに出来ているかを確認するために、試験仕様書を作成します。試験項目の作成は、要素設計者以外が実施することが望まれます。要素設計者は思い込み(たとえば、修正する予定で他の結果を待つなどの理由で未実施であったものを、修正済みであると勘違いするなど)があるためです。
試験仕様書に基づいて試験を実施し、試験方法と結果について安全方針のトレースに残します。
また、試験結果の判断は、要素設計者が単独で実施するのではなく、判断ができるレベルの知識を持ち合わせた他者も実施することが、信頼性の向上や安全性説明のために重要です。
統合試験(システム設計仕様書レベル)
 システム設計仕様書を元に試験を実施します。
 システム設計仕様書に規定している通りに出来ているかを確認するために、試験仕様書を作成します。同様に、試験項目の作成は、システム設計者以外が実施することが望まれます
試験仕様書に基づいて試験を実施し、試験方法と結果について安全方針のトレースに残します。
また、試験結果の判断は、要素設計者が単独で実施するのではなく、判断ができるレベルの知識を持ち合わせた他者も実施することが、信頼性の向上や安全性説明のために重要です。
製品試験(要求仕様書レベル=Verification)
 要求仕様書を元に試験を実施します。
 要求仕様書に規定している通りに出来ているかを確認するために、試験仕様書を作成します。同様に、試験項目の作成は、要求仕様書作成者以外が実施することが望まれます
試験仕様書に基づいて試験を実施し、試験方法と結果について安全方針のトレースに残します。
要求事項に耐久性が記載されている場合には、耐久試験も実施します。
また、試験結果の判断は、要素設計者が単独で実施するのではなく、判断ができるレベルの知識を持ち合わせた他者も実施することが、信頼性の向上や安全性説明のために重要です。
製品試験(Validation)
 要求仕様書どおりに製品ができていたとしても、製品として問題がないかを試験します。
 試験仕様書は様々なケースを想定して作成します。同様に、試験項目の作成は、要求仕様書作成者以外が実施することが望まれます
試験仕様書に基づいて試験を実施し、試験方法と結果について安全方針のトレースに残します。
また、試験結果の判断は、要素設計者が単独で実施するのではなく、判断ができるレベルの知識を持ち合わせた他者(出来たら部外者)も実施することが、信頼性の向上や安全性説明のために重要です。

5.その他

開発全般で問題となる項目及び当事務所で対応可能なサービス

レビュー実施レベル
 各フェーズでのレビューが必要となりますが、発注元のレビュー担当者の設計経験がありすぎるために、踏み込みすぎたレビューが行われることが多々見受けられます。要求仕様書を出した側がレビューする場合には、要求仕様書の記載の範囲内でなければいけません。
たとえば、「~Vで逆接続に耐える事」との要求を出している場合、得てして「逆流防止ダイオードがここに入っていますか?」などの質問をしがちです。このような質問を実施することは、この部分に対して問題が発生した場合に発注元の責任となりえます。正しくは、受注側に要求を満たすことを説明させて、問題が無いかを確認する事です。
チェンジマネージメント時の問題対応
 システム開発中に齟齬などが発生した場合、手戻りさせて方向性を修正することになります。
手戻りの影響範囲を手早く判断するためにPLMを導入されている場合も多いと思います。しかしながら、PLMを導入したとしても、十分に構造化されていないと、「結局はほとんどやり直し。」になります。
システムを構造化することにより、修正範囲を限定することが可能になります。

その他も関連する作業につきましても、対応可能な項目もございます。お問い合わせください。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

two × 3 =