機能安全、パート4/7。管理および評価プロセス

ハブ全体がハブのセキュリティに専念しており、おそらく、「セキュリティ」の概念に正確に何が投資されているのか誰も考えていないので、すべてが明確です：情報セキュリティ（セキュリティ）。 しかし、安全性、安全性、人間の健康と生命、環境へのリスクに関連する別の側面があります。 情報技術自体は危険ではないため、通常は機能コンポーネント、つまりコンピューターシステムの適切な機能に関連するセキュリティについて話します。 インターネットの出現により情報セキュリティが重要になった場合、事故が常に発生するため、機能制御はデジタル制御の出現前に検討されました。

この記事は、機能安全に関する一連の出版物の続きです。

この記事では、機能安全管理のかなり抽象的な要件が、作業プロセスでの実装について解釈されます。 この情報は、いくつかの認証プロジェクトによって実際に検証および洗練されています。
プロセス工学-それは退屈ですか？ ITビジネスの規模を拡大できるのはプロセスです。 私は個人的に、プロセスを開発に導入することで、パフォーマーと会社全体の両方が深刻な専門的成長につながったことを観察する必要がありました。 逆もまた同様です。「プラグ」と、未熟性やその他の重大な問題を証明する適切に構造化されたプロセスを導入するいわゆる「不便さ」。
だから...

前の記事では、機能安全要件の構造が考慮されました（図1を参照）。 次に、機能安全管理と機能安全評価の2つの側面に焦点を当てます。



図1. IEC 61508の要件の構造

機能安全管理計画

機能安全管理プロセスは、多くの点でプロジェクト管理（PM）および機能成熟度モデル統合（CMMI）プロセスと一致しています。

IEC 61508およびその他の関連規格（IEC 61511、IEC 62061、ISO 26262、EN 50129、IEC 62304など）の要件を満たすために、機能安全管理をどのように編成できるかを検討してください。

このような要件は、IEC 61508-1,2,3に含まれる条項6に含まれています。 要件の主な範囲はIEC 61508-1に示されています。 IEC 61508-2にはパート1への参照のみが含まれ、IEC 61508-3にはソフトウェア構成管理への追加が含まれます。

次に、これらの要件とこれらの要件を満たすために必要なアクションを理解してみましょう。 実際には、このための特別なドキュメントである機能安全管理計画（FSMP）を開発することが最善です。 このような計画には、いくつかの領域が含まれます。
-人事管理;
-構成管理。
-開発ツールの選択と評価（ツールの選択と評価）;
-検証と検証。
-ドキュメント管理。
-機能安全評価。

これらすべてのポイントについては、記事の関連セクションで以下で説明します。 それらの特徴は、各領域が他の領域からかなり広範かつ動的で部分的に自律的なプロセスであるため、それぞれが独自の個別のドキュメント（計画およびレポート）を開発および維持することをお勧めします。 FSMPでは、基本的なポイントを詳細なしで残すことが理にかなっています。

さらに、FSMPには次のセクションを含める必要があります（これらは非常に単純であるか、この出版物の範囲外であり、ライフサイクルの説明に関する計画出版物で検討されます）。
-プロジェクトのポリシーと戦略（プロジェクトのポリシーと戦略）は、プロジェクトの目標がどのように、なぜ達成されるのかという、かなり宣言的な説明です。 実際、このパートでは、FSMPの主な規定を要約できます。
-サプライヤー管理には、機能安全の提供に影響する製品およびサービスのサプライヤーとのやり取りが含まれます。 この要件は、品質管理システム（ISO 9001）からのものでした。 プロジェクト管理の観点から見ると、調達管理は類似しています。 IEC 61508では、サプライヤに品質管理システムを導入するよう要求しています。 サプライヤーがISO 9001証明書を持っている場合、問題はありません（逆も同様）。
-情報セキュリティ（セキュリティ）; IEC 61508はこの重要な特性について簡単に述べているだけであり、もちろん、この側面に注意が払われていないという意味ではありません。 これらのプロパティは他の標準で説明されており、要件に応じた認証は別のプロセスです。 ここで考慮されるプロセスコンポーネントに関しては、少なくとも、情報セキュリティ管理システムの要件と矛盾しません（たとえば、ISO 27000に従って認証されています）。
-機能安全ライフサイクルは、FSMPの段階で説明する必要があります。 このコンポーネントは別の出版物で検討し、要件のトレースの隣接プロセス（要件トレース）も検討します。

したがって、考慮されるFSMP構造は、マインドマップの形式で以下に示されています。



図2.機能安全管理計画（FSMP）の構造

すでに述べたように、機能安全の管理における多くの規定は重複しているか、プロジェクト管理から直接借用されています。 さらに、体系的な障害に対する保護方法の1つとして、IEC 61508でプロジェクト管理の適用が推奨されています。 したがって、プロジェクトのチャーター、WBSに基づくプロジェクト計画、アクションおよびバグトラッカーなどのツール。 暖かく歓迎され、使用が推奨されます。 標準の要件に従って行われるべきことに焦点を当てます。

人事管理

原則として、会社が既にプロジェクト管理（PMBOOK）方法論または類似の方法（CMMIなど）を使用している場合、原則として、この方向で特別なことは何も行わないでください。 IEC 61508では、実用的なアクションが必要です。
-必要なすべてのアクションを実行する責任者を任命します。 機能安全の確保と評価に関連する活動を調整する必要性についても話しているため、いわゆる機能安全コーディネーターを任命することをお勧めします（または、プロジェクトマネージャーにそのような機能を割り当てることもできます）。
-サードパーティの参加者を含むプロジェクト担当者間のコミュニケーション手順を決定します。
-FSMPにリストされているすべての領域をカバーする必要なすべての手順を開発します。
-必要なレベルでの能力の維持を保証し、必要なスタッフトレーニングを編成します。

前述の（および個人的な経験から）に基づいて、このようなプロジェクトの人事管理の主なツールは、組織図と能力マトリックスです。
詳細な人事管理計画のために、適切な計画（人材管理計画）を作成します。 この計画は組織全体には適用されず、セキュリティに重要な製品（ソフトウェアまたはシステム）を開発する認定プロジェクトの参加者にのみ適用されることに注意してください。 含まれている必要があります（図3を参照）。
-プロジェクトの役割の説明を含むプロジェクトの組織図。
-ライフサイクルのさまざまな段階で作業を計画および実行するためのプロジェクトの役割と責任を示すプロジェクト参加者のリスト。
-指名された出演者の能力または能力の不足に関する能力と結論のマトリックス（つまり、特定のプロジェクトの役割に必要な知識とスキル、および特定の従業員がどれだけ彼らに対応しているか）; ここで疑問が生じる場合があります。「能力が不十分な人をどのように任命できるか」。 ただし、現実の世界では、リソース、主に人的リソースの不足が常に観察されます。 肯定的なニュースは、多くのパフォーマーの能力の重大な不足の場合、不足しているスキルと知識を教えることができるということです。
-プロジェクトの実施に不可欠な上記の能力を達成および維持することを目的としたスタッフトレーニング活動。 トレーニング計画とレポートを文書化する必要があります。
-プロジェクト参加者のコミュニケーション計画。
-スタッフの署名が記載されたシート。この計画に精通していることを示します。



図3.人事管理計画の構造

構成管理

この方向は、PMBOOKおよびCMMIと共通点があるため、非常によく知られており、方法論的に開発されています。 機能安全の観点から、構成管理には変更管理と、廃止を含むソフトウェアおよびハードウェアの変更の実装も含まれます。 さまざまなインシデントが変更を加えるための入力であるため、危険なイベントの分析は同じ領域に分類されます。 また、ソフトウェア構成管理計画のためのIEEE 828標準から、そしてもちろん、例えば、 @ Aguaryの「退職したsiemshchikによるメモ」など、Habrの著者のブログから、多くの有用なポイントを収集できます。

機能セキュリティのコンテキストで構成アイテムを定義するときは、おなじみのソースとプログラムコードのビルドだけでなく、開発ツールとテストツール（それらについては少し後で）、設計の完全なセット、ユーザーも含まれることを理解することが重要です設計ドキュメントを含む、その他の関連ドキュメント（これもわずかに低くなります）。これに応じて、すべての機械、電気、電子コンポーネントが作成されます（図4を参照）。



図4.典型的な構成アイテム

このような構造は、プロジェクトリポジトリの基盤として機能します。 ドキュメントとツールについては、以下で詳しく説明します。

構成管理は使用するツールに直接依存しますが、次のような「構成管理計画」（構成管理）に含める必要があるいくつかの一般的なポイントがあります（図5を参照）。
-構成管理プロセスのプロジェクト参加者の役割と責任。 主要なプロジェクト参加者の構成および変更管理グループは、変更を行う際に意見を考慮することが重要であるすべての個人が関与して編成される必要があります。
-構成管理プロセスを計画および維持するためのアプローチ。
-構成管理プロセスのリソース、主に使用されるツール（SVN、Gitなど）。
-すべての構成コンポーネント（構成アイテム）および基本バージョン（ベースライン）の形成を識別する手順。
-製品のソフトウェアおよびハードウェアコンポーネントのバージョンを管理し、それらのステータスを説明するツールの使用手順。
-構成コンポーネントとバックアップストレージにアクセスする手順。
-構成監査の手順と頻度。
-操作中に発見された欠陥を含む、検出された欠陥の分析と除去の手順（これは、次の項目の可能な入力の1つです-変更管理）。
-影響分析および変更の検証を含む、変更管理手順。



図5.構成管理計画の構造

変更管理プロセスは、プロセスの実装と認証に不可欠です。 正式化には、通常、変更要求の段階的な処理が使用されます。 変更を行うための手順は、以下の図に示されています（図6を参照）。
送信-変更要求の受信。理由は修正または改訂の可能性があります。
承認-リクエストのレビューと正式な承認。 もちろん、リクエストは拒否される可能性があり、その後のステップは実行されません。
影響分析-機能、セキュリティ、量、作業コストなどに対する要求の影響の分析。 開発の範囲だけでなく、ドキュメント、テスト、および検証と検証に関連するその他のチェックの変更も定義します。
実装-変更の直接実装。
検証-行われた変更に関するさまざまな種類の検証チェックを実行します（段階的に実行できます）。
閉じる-変更要求の正式な閉鎖。



図6.変更要求の処理に基づく変更管理プロセス

開発ツールの選択と評価（ツールの選択と評価）

計装（IS）の選択および評価活動は機能安全管理に密接に関連していますが、要件はIEC 61508-3（7.4.4プログラミング言語を含むサポートツールの要件）に概説されています。

最終製品（システムおよびソフトウェア）への影響度に応じて、ツールは次のように分類されます。
-T1クラスツールは、実行可能コードに直接影響する出力を生成しません。 これには、テストおよびグラフィカルエディター、構成管理ツール（コードを直接生成しないもの）、アクションおよびバグトラッカーが含まれます。
-T2クラスツールは、テストおよびその他の種類の検証（たとえば、静的コード分析またはテストカバレッジの完全性の分析）をサポートします。 ただし、実行可能コードには直接的な影響はありませんが、テストツールの問題により、ソフトウェアのエラーが検出されない可能性があります。 このクラスには、ソフトウェアだけでなく、入出力信号のハードウェアとソフトウェアのシミュレータも含める必要があります。 機械部品、電気部品、電子部品（プリント基板など）の設計ツールもT2に分類できることに注意してください。
-T3クラスツールは、実行可能コードに直接影響する出力を生成します。これには、トランスレーターとコンパイラー、アセンブリーをサポートするスクリプト、コントローラー構成の観点からのSCADAが含まれます。



図7.機能安全関連プロジェクトの典型的なツールの分類

コンパイラを機能セキュリティの目的で使用する可能性を正当化することは、実行可能コードの生成に影響するすべての機能の完全なテストを実行する必要があるため、機能セキュリティ目的でコンパイラを使用することの最大の問題です。 開発者から個人的にそのような情報を入手することは不可能であり、他の誰かのコンパイラの100％テストを独自に実施することも少し難しい作業です。 幸いなことに、近年、多くのプログラマブルチップ（CPU、FPGA / CPLD）の大手メーカーが、IEC 61508に準拠したコンパイラバージョンをすでに市場に投入しています。 このようなツールは、IEC 61508の要件を満たす製品の開発に使用できます。ここには2つの問題があります。そのようなツールの多くのコスト（通常は数千ドル）と、コンパイラの典型的なバージョンでサポートされるすべてのマイクロ回路と互換性がないという事実です。

ツールに近い分野は、限られた安全なプログラミング言語構成要素のセットの使用を必要とするコーディング規則の選択と適用です。

ツールを使用するときは何を探すべきですか？ IEC 61508の要件で指定されているいくつかの規定があります。
-クラスT2およびT3のツールの場合、操作がどのように発生するかを明確に説明する要件仕様またはユーザーマニュアルを入手できるようにする
-クラスT2およびT3のツールの場合、要件仕様またはユーザードキュメントへの準拠は、たとえば証明書の形式で文書化する必要があります。
-指定された条件のすべてのバージョンが満たされるわけではないため、使用されるツールのバージョンを監視する必要があります。 すべてのプロジェクト参加者は同じバージョンを使用する必要があります。 バージョン間の移行には、適切な手順を適用する必要があります。
-ツールが単一の技術的複合体として使用される場合（たとえば、仕様に基づいてコードとテストが生成される）、相互の互換性をテストする必要があります。

これらの要件への準拠を確実にするために、ツールの選択と評価に関する特別なレポート（ツール選択および評価レポート、TSER）を作成することをお勧めします。 以下を含む必要があります。
-製品の開発、テスト、およびサポートプロセス（構成管理、テキストドキュメントのセット、プロジェクト管理など）に使用される使用済みツールスタック（市販および専用のソフトウェアとハ​​ードウェアの両方）の説明）; 各ツールについて、次を示す必要があります。タイプ（使用するプロセスをサポートするため）、名前、バージョン番号、ベンダー名、クラス（T1、T2またはT3）、構成コンポーネント（構成アイテム）に関して生成された出力。
-特定のプロジェクトで実行される機能とその適用性、使用経験、利用可能な文書、サプライヤに関する情報（市場の評判、品質管理システム、構成管理アプローチなど）など、指定された基準セットに従ったツールの評価（分析）の結果など）、製品の安全性への影響、検出および解決されたエラー、故障の兆候に関して使用される可能性のあるリスク、およびこれらのリスクを管理するための戦略。

実績のあるテクノロジースタックを使用してプロジェクトを実行する場合、典型的なTSERを使用または完成させることができます。

検証と検証

このプロセスの実装は、選択したライフサイクルの構造に依存するため、機能安全ライフサイクルのトピックに関する計画された出版物の詳細を検討することは理にかなっています。

検証と検証には、テストだけでなく、プロジェクトドキュメントのレビュー、障害の種類と結果の分析（障害モードと効果分析）、静的コード分析なども含まれることに注意してください。

機能安全を管理するために、次の規定を含む最上位の検証および検証（V＆V）計画を作成することは理にかなっています（図8を参照）。
-V＆Vプロセスの組織と実装のためのリソースの割り当ての説明。
-開発段階に関連するV＆V段階。
-V＆Vを実行するための方法とツール。
-V＆V結果を文書化するための要件。
-検出された異常を処理するための要件。



図8.検証および検証計画の構造

個々のレビュー、分析、およびテストの計画、仕様、およびレポートは通常、独立したドキュメントです。

ドキュメント管理

文書要件は、IEC 61508-1の条項5に含まれています。 基本的な要件は次のとおりです。
-文書には、開発のその後の段階と、現在の段階の結果の検証の両方に十分な情報が含まれている必要があります。
-文書には、機能安全の確保と評価の両方に十分な情報が含まれている必要があります。
-セキュリティに関連する製品（ソフトウェアおよびシステム）の開発および認証に関するプロジェクト担当者がドキュメントを利用できるようにする必要があります。
-ドキュメントには、バージョン番号と最終変更日が必要です。 上記の変更管理手順に従って、ドキュメントを変更する必要があります。

文書管理の詳細な計画については、適切な計画（文書化計画）を作成します。 この計画は組織全体に適用されるのではなく、セキュリティに重要な製品（ソフトウェアまたはシステム）の開発のための認定プロジェクトの参加者にのみ適用されることに注意してください。 含まれている必要があります（図9を参照）。
-文書の識別、開発、実行、承認、承認の要件。
-文書を評価するための手順と基準を確認します（たとえば、チェックリストの形式で）。 特に、IEC 61508に従って文書を評価するための基準は次のとおりです。正確性、簡潔性、わかりやすさ、使用の適合性または適合性、使用および保守の可用性。
-プロジェクトに関するドキュメントのリストと開発責任の配分。
-ドキュメントへのプロジェクト参加者のアクセス権とアクセス権を整理する手順。
-文書、会計方針、バージョンの変更を行う手順。
-電子文書管理システム（EDCS-電子文書制御システム）の使用要件とプロジェクトリポジトリの構造。



図9.ドキュメンテーションプランの構造

私自身の経験に基づいて、これは計画のかなり動的な部分であるため、ドキュメントのリストをドキュメント計画の別の付録に保持するのが便利であると言えます。

機能安全に関連するプロジェクトで開発されたドキュメント。 次のタイプが含まれます（図10を参照）。
-この記事でレビューした機能安全計画文書。
-安全要件仕様（SRS）およびシステムアーキテクチャ（SAD）。
-ハードウェア設計ドキュメントとも呼ばれるハードウェアプロジェクト。
-ソフトウェアプロジェクト（ソフトウェアデザイン）;
-検証と検証に関する文書。
-極度の衝撃に対する耐性に関するいわゆる機器認定試験に関連する文書。 通常、気候（温度-湿度）、機械的（衝撃、共鳴探索、輸送振動、地震）、電磁気などの影響のレベルを設定します。
-上記のツールに関連する文書（ユーザーマニュアル、要件仕様、要件への準拠を確認する証明書、サプライヤーに関する情報）;
-変更管理（変更管理）に関する上記の文書。
-安全のためのユーザーマニュアル（製品安全マニュアル）を含む、提供された製品のユーザーマニュアル。
-作業を整理するためにプロジェクトで使用されるガイド、手順、および指示。 このようなドキュメントは、会社の慣行で使用することも、機能安全プロジェクト専用に開発することもできます。



図10.機能安全関連プロジェクトのドキュメントの分類

機能安全評価

次に、機能安全がどのように評価されるかを見てみましょう。
これを行うには、運用中に定期的な機能安全監査が実施されます。
さらに、認証プロセスでは、認証機関によってプロセスと製品の評価が行われ、その結果に応じて準拠証明書が発行されます。最も有名な機能安全認証機関はテュフグループ企業です。
監査は、機能安全監査計画に従って実施する必要があります。計画では以下を決定する必要が
あります。-監査の頻度（たとえば、各開発段階の完了時）。
-製品およびプロセスに関する評価の領域。
-関係する組織およびその他の必要なリソース。
-指導者の独立性のレベル。監査は内部的なものである場合があり、監査人は監査対象のプロセスに関与していないプロジェクト参加者です。さらに、認証機関は定期的な監査にも参加できます。一般に、セキュリティの評価における独立性の問題は、さまざまな業界で独自の伝統を持っています。
-監査を実施する人の能力。
-期待される結果;
-欠陥をなくすための行動の組織。
監査チェックリストを準備するための初期データは、この記事で説明したFSMPおよびその他の下位計画の要件です。
監査の結果に基づいて、対応する機能安全監査レポートを発行する必要があります。

結論

61508, (Functional Safety Management) (Functional Safety Assessment).
, .
, , , , 61508.
(6 ) exida TÜV .

PS機能安全の主な側面を説明するために、次の一連の記事が開発されています。
- 機能安全のトピックの紹介 。
-IEC 61508規格：用語 。
-IEC 61508規格：要件構造 。
- 情報と産業用制御システムの機能安全との関係 。
- 機能安全の管理と評価のプロセス ;
- 情報と機能セキュリティのライフサイクル 。
- 信頼性と機能安全の理論：基本的な用語と指標 。
- 機能安全を確保する方法 。

ここでは、出版のトピックに関するビデオ講義を見ることができます。