IEC 61508
IEC 61508は、IEC（国際電気標準会議）が制定した基本安全規格(basic safety publication)であり、プロセス産業における電気・電子・プログラマブル電子(Electrical・Electronic・Programmable Electronic)（以下、E/E/PE）機能安全に関する国際規格である。E/E/PEの機能または故障・障害によって人命、環境、財産に大きな影響を与えるものなどを対象とする。機械だけで構成する装置はIEC 61508の対象外である。IEC 61508は、プラント、発電所、機械、鉄道､医療機器、家電やシステムのリスクを軽減するために使用するコンピュータ・ソフトウェアを含むE/E/PEによる安全性を高めるための機能安全規格である。また、これらの設計製造・運用保守・改修廃却に至る全製品生存期間（ライフサイクル）における安全評価の要求や、組織の機能安全能力審査、安全評価者の独立性及び従事者の資質(competency)を記述している。また，確率論的危険（リスク）解析などによって，全体システムのリスクが許容リスクを下回るようにするために，当該安全装置の安全度水準（SIL）を決定する。安全に関わる故障・障害を，システマティック故障（決定論的原因故障）と、確率論的で無作為なランダムハードウェア故障に分類し、安全度水準（SIL:Safety Integrity Level）に応じたリスク低減策（対策）を行う。
2000年にIEC61508の第1.0版が制定された。また，2010年にIEC61508の第2.0版が制定された。
国内ではJIS C 0508「電気・電子・プログラマブル電子安全関連系の機能安全」として、IEC61508のFDIS、CDV段階のものを1999年に制定している。2012年にJIS C 0508の第2.0版が制定された。
IEC 61508規格書は、Part1からPart7で構成され、IEC61508-1,IEC61508-2,IEC61508-3,IEC61508-4が規定、IEC61508-5,IEC61508-6,IEC61508-7が参考となっている。
マネジメントと文書化の規定
　　ハードウェア（一部、システムやソフトウェア関連も含む）
規格書自体難解で、読み解くには多様な専門分野の知識が必要である。また、規格書の中で紹介される技法は参考文献が古かったり、入手困難な場合がある。規格書の理解を助ける日本語の文献はまだ少ない。
IEC 61508は、グループ安全規格であるとする日本国内の解説書があるが、IEC61508-1,IEC61508-2,IEC61508-3,IEC61508-4はIEC GUIDE 104に基づく基本安全規格(basic safety publication(s))である。
また、IEC 61508は、A規格ではない。ISO/IEC GUIDE 51の規格体系の中で、A規格、B規格、C規格という定義がされているが、IEC 61508はIEC GUIDE 104の規格体系に基づく。
IEC 61508は、「state of the art」の技術を製品に適用し、ランダムなハードウェア故障を検知して安全状態にすることによって安全性を高めることを基本的な考えとしている。
安全性の目標として、安全度水準（SIL）が定義されており、以下のように規定されている。
規格で定義する原因別の故障の種類は以下の２つである。また、原因別の分類以外に、共通原因故障と従属故障、安全側故障と危険側故障などが定義されている。
ソフトウェア及びハードウェアの設計開発の中で、仕様の曖昧さ、設計の想定外、テスト漏れを原因としたフォールト、不具合、バグを対象とした故障である。
JIS規格では、｢正しい知識，認識，対策の欠如などの原因の決定的に関連する想定外の故障又は失敗。この原因は，設計の部分改修，製造過程，運転手順，文書化又はその他の関係する要因の修正によってだけ除くことができる［IEV 191(IEC 60050-191)-04-19］｣と定義されている。
システマティック故障対策は、故障回避と、故障コントロール（管理または制御）からなる。システマティック故障は，設計の誤りや製造誤り（ミス）など、主に人間の失敗（エラー）によるもので，これに対しては全安全循環（ライフサイクル)の16段階（フェーズ）における安全評価・対策により防ぎ、再発防止のための文書化を要求している。
ハードウェアの故障率曲線の中で、ランダム故障期間（コンスタント故障期間）を対象とした故障である。JIS規格では、ランダムハードウェア故障は「時間に関して無秩序に発生し，ハードウェアの多様な劣化メカニズムから生じる故障」と定義されている。主にハードウェアに関し，部品や材料の劣化、製品のばらつきなどにより起こるものであり，これに対しては，冗長化や多様化によるシステムの信頼性向上や自己診断機能設置などの対策が必要である。
ソフトウェアの故障はすべてシステマティック故障であり、ランダム故障は存在しないというのが規格の考えである。
ランダムハードウェア故障は回避できないため、ランダムハードウェア故障対策は、故障コントロール（管理または制御）からなる。ランダムハードウェア故障を「安全側故障」と「危険側故障」、さらに「検知できない故障」と「検知できる故障」で分類し、最も危険である「危険側故障、かつ検知できない故障」が目標とする安全度水準で規定するPFD、PFH未満であることを証明するエビデンスを残す。
規格要求は、安全機能の定義～実装とトレーサビリティ、安全度(安全完全性)の定量化と目標値達成のエビデンス、責任の明確化や検証可能性等のための文書化の3つである。
安全度の目標値達成をするためには、定性的な故障対策と定量的な故障対策が必要であり、故障回避、故障コントロール（管理または制御）からなる。
システマティック故障（決定論的原因故障）およびランダム故障の対策として規格が要求する内容は大まかに6つである。
さらに上記の対策を確実にするために，組織の機能安全評価能力の診断や，組織を構成する個人の資質あるいは行動特性(compitency)を包含する形となっている。IEC 61508では，安全関連系のハードウェア設計に当って，自己診断技法や，各種故障を抑制する技法，さらに，共通原因故障への対策など多数の具体的な最良の経験（ベストプラクティス）を提示していて，各々をSILに応じて採用するとよいとしている。
ソフトウェアの故障（不具合）は決定論的原因故障である。ソフトウェアでは故障（不具合）は製作時に組み込まれており，一般のランダムハードウェア故障に対する確率論的なアプローチを採用できない｡
IEC61508では，ソフトウェアに対して，安全ライフサイクルにおいてSILに応じて指定するソフトウェア技法の採用を推奨または強く推奨している。
機能安全マネジメントは、ISO9001に類似しているが、以下のような違いがある。
機能安全マネジメントに関する規格要求を整理すると、以下の責任と権限の分担が必要である。
組織は組織全体の責任者、プロジェクト全体の責任者と、各フェーズの責任者を決定する。兼務してもよい。責任者は、機能安全管理については専門知識を有する人員に委任・付託することが望ましい。
責任者は機能安全の専門知識を有する機能安全管理者を任命する。規格では責任者が機能安全管理者と兼務することを禁止していないが、機能安全管理者は少なくともプロジェクト責任者と同格の地位を有する別人とする方が望ましい。機能安全管理者は、機能安全アセッサーと機能安全監査者を任命する。
機能安全管理者は機能安全の専門知識を有し、目標SILに応じて独立性が要求される機能安全アセッサーを任命する。通常、責任者や機能安全管理者、設計開発部の人員は、機能安全アセッサーを担当しない。少なくとも品証部の管理職や機能安全の専門組織の管理職、機能安全の認証機関が担当する。対象製品の機能安全の達成をアセスメント（評価）する。
機能安全管理者は機能安全のプロセスを理解し、プロセスでの不備を指摘する機能安全監査者を任命する。組織内部のプロジェクト関係者以外の人員が担当してもよいし、認証機関の機能安全アセッサーが担当してもよい。
プロジェクト責任者は機能安全ライフサイクルにおける各フェーズの責任者、担当者および検証者を任命する。担当者と検証者は別人である必要がある。機能安全に精通しているほうが望ましい。
機能安全マネジメントに関わる人員は、その役割に応じて機能安全に精通していることを証明しなければならない。一般には、認証機関や団体で行われる。トレーニングコースを受講して証明する。日本では、一般財団法人 日本規格協会やTÜV Rheinland社、TÜV SÜD社で、トレーニングが行われている。
認証機関による機能安全規格適合認証は、製品認証やプロセス認証などがある。
対象製品の目標SILがSIL3以上においては、認証機関よる審査を行う。
製品認証は、認証機関によって多少の違いがあると思われるが、一例を以下に示す
コンセプト審査フェーズとメインインスペクションフェーズ、認証フェーズに分かれる。
コンセプト審査フェーズでは、安全計画書、V&V計画書、安全要求仕様書、安全コンセプト説明書の4文書を提出する。
　　プロジェクトの機能安全マネジメント（組織、担当責任者の適正能力、安全設計 での導入方策と技法）を具体的に記述したもの
設計プロセスの各フェーズで、どんなツールで、どのような検証・妥当性確認を 実施し、その結果をどのように文書化するのかを記述したもの
どんな安全状態・システム・動作環境を想定しているかなど、必要な安全要求仕 様を具体的に記述したもの
SRSを基にどのように安全機能を実現するか（特にタイミング、非安全関連部から 安全関連部への影響回避方策など）を具体的に記述したもの