機能安全に触れる機会があり、技術・手法群についてもとても勉強になりそうであったため、一つずつ理解していきたい
IEC 61508-3：2010 附属表A
IEC 61508-3：2010 附属表Aにおいて、要求安全度水準に従って採用すべき技術・手法が規定されている。
以下の表はIEC 61508-3：2010 附属表Aより引用
https://kikakurui.com/c0/C0508-3-2014-01.html
| 評価 | 説明 |
|---|---|
| HR | この安全度水準には、技法又は手段を使用することを強く推奨する。この技法又は手段を使用しない場合は、使用しない理論的根拠について、附属書Cを参照して安全計画時に詳述しなければならず、またアセッサと合意しなければならない。 |
| R | この安全度水準には、HR推奨より低い推奨事項としての技法又は手段が望ましい。 |
| -– | 技法又は手段を使用することに関しては、推奨も反対もしない。 |
| NR | この安全度水準には、技法又は手段を使用することを積極的には推奨しない。この技法又は手段を使用する場合は、使用する理論的根拠について、附属書Cを参照して安全計画時に詳述しなければならず、またアセッサと合意することが望ましい。 |
表A.2−ソフトウェア設計及び開発−ソフトウェアアーキテクチャ設計（7.4.3参照） の一部抜粋
https://kikakurui.com/c0/C0508-3-2014-01.html
| ID | 技法及び手段 | 参照先 | SIL 1 | SIL 2 | SIL 3 | SIL 4 |
|---|---|---|---|---|---|---|
| 5 | 人工知能−フォールト修正 | IEC 61508-7の C.3.9 | -– | NR | NR | NR |
| 6 | 動的再構成 | IEC 61508-7の C.3.10 | -– | NR | NR | NR |
| 7 | モジュラーアプローチ | 表B.9 | HR | HR | HR | HR |
| 8 | 信頼性確認及び検証済ソフトウェア要素の使用（利用できる場合） | IEC 61508-7の C.2.10 | R | HR | HR | HR |
| 9 | ソフトウェア安全要求仕様及びソフトウェアアーキテクチャとの間の前方トレーサビリティ | IEC 61508-7の C.2.11 | R | R | HR | HR |
| 10 | ソフトウェア安全要求仕様及びソフトウェアアーキテクチャ間の後方トレーサビリティ | IEC 61508-7の C.2.11 | R | R | HR | HR |
| 11a | 構造化図表法b) | IEC 61508-7の C.2.1 | HR | HR | HR | HR |
| 11b | 準形式手法b) | 表B.7 | R | R | HR | HR |
| 11c | 形式的設計手法及び精緻化手法b) | IEC 61508-7の B.2.2及びC.2.4 | -– | R | R | HR |
| 11d | 自動ソフトウェア生成 | IEC 61508-7の C.4.6 | R | R | R | R |
| 12 | コンピュータ支援仕様書作成ツール コンピュータ支援設計ツール | IEC 61508-7の B.2.4 | R | R | HR | HR |
| 13a | 最大周期を保証した周期的挙動 | IEC 61508-7の C.3.11 | R | HR | HR | HR |
| 13b | タイムトリガアーキテクチャ | IEC 61508-7の C.3.11 | R | HR | HR | HR |
IEC 61508-7：2010
IEC 61508-7：2010にて以下の定義が示されている
C.2.9 モジュラーアプローチ
注記 この技術及び手法は，JIS C 0508-3の表A.4及び表B.9で引用されている。
目的：ソフトウェアシステムを，システムの複雑さを制限するために小さな理解できる部分に分解する。
説明：モジュラーアプローチ又はモジュール化は，ソフトウェアプロジェクトの設計，コーディング及び保全の各フェーズについての幾つかの規則を含む。これらの規則は，設計時に採用する設計方法によって異なる。ほとんどの方法は，次の規則を含む。
− 一つのソフトウェアモジュール（又は，同様に，サブプログラム）は，明確に定義した実行するタスク又は関数を一つだけもつことが望ましい。
− ソフトウェアモジュール間の接続は，制限し厳密に定義することが望ましく，一つのソフトウェアモジュールの一貫性は強力でなければならない。
− サブプログラムの集合を作成し，この集合は幾つかの水準のソフトウェアモジュールを備えることが望ましい。
− サブプログラムのサイズは，ある規定値，典型的な値としては2〜4スクリーンサイズに制限することが望ましい。
− サブプログラムは，唯一の入口点及び唯一の出口点をもつことが望ましい。
− ソフトウェアモジュールは，インタフェースを介して他のソフトウェアモジュールと通信することが望ましい。大域変数又は共通変数を用いる場合，これらを十分に構造化し，アクセスを制御し，各インスタンスにおいて正当化して用いることが望ましい。
− ソフトウェアモジュールの全てのインタフェースは，完全に文書化することが望ましい。
− ソフトウェアモジュールのインタフェースは，この関数に必要なパラメータだけを含むことが望ましい。ただし，この推奨事項は，プログラミング言語がデフォルトのパラメータをもつか，又はオブジェクト指向アプローチを採用する可能性があるため，複雑になることがある。参考文献： The Art of Software Testing, second edition. G. J. Myers, T. Badgett, T. M. Codd, C. Sandler, John Wiley and Sons, 2004, ISBN 0471469122, 9780471469124 Software Engineering for Real-time Systems. J. E. Cooling, Pearson Education, 2003, ISBN 0201596202, 9780201596205 Concepts in Programming Languages. J. C. Mitchell. Cambridge University Press, 2003, ISBN 0521780985, 9780521780988
https://kikakurui.com/c0/C0508-7-2017-01.html
javaでのmoduleシステム
Java 9以降、Java言語には正式にモジュールシステムが導入されました。これにより、アプリケーションをモジュール単位に分割し、各モジュールが独立して開発・管理できるようになりました。
モジュール定義:
- 各モジュールは
module-info.javaファイルで定義され、モジュール間の依存関係や公開するパッケージを指定できます。
module com.example.moduleA {
exports com.example.moduleA.publicapi;
requires com.example.moduleB;
}
コンテナベース
近年の大規模なソフトウェア開発では、ModuleどころかModuleをコンテナとして独立して作成し、コンテナ毎に機能を管理することが潮流となっています。
特にjava等の言語ではModuleで機能を定義した場合、リリースするためにはどのみち全体のビルドとリリースプロセスが必要になります。一方で、コンテナベースに分割することで、コンテナ毎に機能をアップデートすることが可能となります。その点で、世間的にもコンテナベースでの開発が注目を集めています