(57)【要約】【課題】複数の要素に機能分割された制御システムの設計の検証を、効率よく実施することを可能にする。【解決手段】設計支援システムに係る制御システムは、複数の作動部の作動に関し直列の関係にある複数の機能部を有しており、前記複数の機能部は、前記複数の機能部の間で前記作動部の作動のための信号の送り側となる第１機能部と、前記信号の受け側となる第２機能部と、を含むものである。当該設計支援システムは、前記第１機能部から前記第２機能部へ供給される信号に関する検証結果を取得する取得部と、前記第１機能部から前記第２機能部へ供給される信号に関する前記第１機能部側の第１の検証結果の入力の有無と、上記信号に関する前記第２機能部側の第２の検証結果の入力の有無と、の少なくとも一方を報知可能とする報知部と、を備える。【選択図】図１９
2018140760.tif 000002
【特許請求の範囲】
【請求項１】
車両の運転者の操作または車両の司令部の指示に応じて前記車両の少なくとも一部を作動させるための制御システムの設計支援システムであって、
前記車両は、複数の作動部と、前記複数の作動部を制御するための制御システムとを有しており、
前記複数の作動部のうちの任意の作動部は、前記運転者の操作または前記司令部の指示に基づいて作動するように設定されており、
前記制御システムは、少なくとも前記任意の作動部に関する複数の機能部であって、前記作動部の作動に関し直列の関係にある複数の機能部を有しており、
前記複数の機能部は、前記複数の機能部の間で前記作動部の作動のための信号の送り側となる第１機能部と、前記信号の受け側となる第２機能部と、を含むものであって、
当該設計支援システムは、
前記第１機能部から前記第２機能部へ供給される信号に関する検証結果を取得する取得部と、
前記第１機能部から前記第２機能部へ供給される信号に関する前記第１機能部側の第１の検証結果の入力の有無と、上記信号に関する前記第２機能部側の第２の検証結果の入力の有無と、の少なくとも一方を報知可能とする報知部と、
を備えることを特徴とする設計支援システム。
【請求項２】
前記機能部に関する検証のための条件を含む情報を記憶する記憶部
を備え、
前記報知部は、
前記検証のための条件を含む情報を表示手段に表示させる
ことを特徴とする請求項１に記載の設計支援システム。
【請求項３】
前記報知部は、
前記第１の検証結果と前記第２の検証結果とに基づいた前記第１機能部と前記第２機能部に関する設計段階を報知する
ことを特徴とする請求項１又は請求項２記載の設計支援システム。
【請求項４】
車両の運転者の操作または車両の司令部の指示に応じて前記車両の少なくとも一部を作動させるための制御システムの設計支援システムであって、
前記車両は、複数の作動部と、前記複数の作動部を制御するための制御システムとを有しており、
前記複数の可動部のうちの任意の作動部は、前記運転者の操作または前記司令部の指示に基づいて作動するように設定されており、
前記制御システムは、少なくとも前記任意の作動部に関する複数の機能部であって、前記作動部の作動に関し直列の関係にある複数の機能部を有しており、
前記複数の機能部は、前記複数の機能部の間で前記作動部の作動のための信号の送り側となる第１機能部と、前記信号の受け側となる第２機能部と、を含むものであって、
当該設計支援システムは、少なくとも、
前記第１機能部に関する情報と、
前記第２機能部に関する情報と、
前記第１機能部から前記第２機能部へ供給される信号に関する情報と、
少なくとも前記第１機能部または前記第２機能部の設計または検証に関わる人に関する情報と、を表示手段に表示させる報知部
を備えることを特徴とする設計支援システム。
【請求項５】
前記機能部に関する検証のための条件を含む情報を記憶する記憶部
を備え、
前記報知部は、
前記検証のための条件を含む情報を表示手段に表示させる
ことを特徴とする請求項４に記載の設計支援システム。
【請求項６】
前記設計支援システムは、
前記機能部に関する検証結果を取得する取得部
を備え、
前記報知部は、
前記第１機能部から前記第２機能部へ供給される信号に関する前記第１機能部側の第１の検証結果の入力の有無と、上記信号に関する前記第２機能部側の第２の検証結果の入力の有無と、の少なくとも一方を報知可能とする
ことを特徴とする請求項４又は請求項５に記載の設計支援システム。
【請求項７】
ユーザーの操作に応じて駆動部を駆動させる制御システムを設計対象とし、当該制御システムに関する機能安全の設計を支援する設計支援システムであって、
当該制御システムは、複数の機能部を含み、前記複数の機能部には前記駆動部を駆動させるための処理が当該処理の流れに従って機能分割されて割り付けられており、前記複数の機能部のそれぞれが、それぞれに割り付けられた処理を実施して前記駆動部を駆動させるものであり、
前記複数の機能部のうち、前記処理に係る指令を送出する第１機能部と、前記第１機能部から送出された指令を受ける第２機能部とについて、前記第１機能部と前記第２機能部との間の前記指令に係る信号が、前記機能分割に従い決定され、前記第２機能部の機能と当該信号との関係が前記機能安全の要求度を満足することを検証する検証部
を備える設計支援システム。
【請求項８】
ユーザーの操作に応じて駆動部を駆動させる制御システムを設計対象とし、当該制御システムに関する機能安全の設計を支援する設計支援方法であって、
当該制御システムは、複数の機能部を含み、前記複数の機能部には前記駆動部を駆動させるための処理が当該処理の流れに従って機能分割されて割り付けられており、前記複数の機能部のそれぞれが、それぞれに割り付けられた処理を実施して前記駆動部を駆動させるものであり、
前記複数の機能部のうち、前記処理に係る指令を送出する第１機能部と、前記第１機能部から送出された指令を受ける第２機能部とについて、前記第１機能部と前記第２機能部との間の前記指令に係る信号が、前記機能分割に従い決定され、前記第２機能部の機能と当該信号との関係が前記機能安全の要求度を満足することを検証する過程
を含む設計支援方法。
【請求項９】
ユーザーの操作に応じて駆動部を駆動させる制御システムを設計対象とし、当該制御システムに関する機能安全の設計を支援する設計支援システムのコンピュータに実行させるためのプログラムであって、
設計を支援する対象の制御システムは、複数の機能部を含み、前記複数の機能部には前記駆動部を駆動させるための処理が当該処理の流れに従って機能分割されて割り付けられており、前記複数の機能部のそれぞれが、それぞれに割り付けられた処理を実施して前記駆動部を駆動させるものであり、
前記複数の機能部のうち、前記処理に係る指令を送出する第１機能部と、前記第１機能部から送出された指令を受ける第２機能部とについて、前記第１機能部と前記第２機能部との間の前記指令に係る信号が、前記機能分割に従い決定され、前記第２機能部の機能と当該信号との関係が前記機能安全の要求度を満足することを検証するステップ
を含むプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、設計支援システム、設計支援方法、及びプログラムに関する。
【背景技術】
【０００２】
各種設計支援システムにより、制御システム等の設計作業の効率を向上させることが図られてきた。その設計の結果が設計者の意図するものであることを検証する必要がある。
近年の移動体は、要求される複数の機能を実現するために、複数の部位、部品を含み、それらの関係が複雑化している。それに伴い、その複数の機能に関する検証も複雑化している。
例えば、車両については、国際規格ＩＳＯ２６２６２（非特許文献１）に規定されるように機能安全の実現が求められ、車両を１つの製品として扱い、製品全体として車１台分の検証が求められるようになった。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】ISO 26262：Road Vehicles-Functional Safety, (2011)
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、非特許文献１を参照しても、車１台分の機能を複数の部位、部品などの要素に分けて構成する際に、実現する機能を如何に分割し、また、その分割の結果を如何にして検証すべきかまでは規定されていない。
本発明の目的は、複数の要素に機能分割された制御システムの設計の検証を、効率よく実施することを可能にする設計支援システム、設計支援方法、及びプログラムを提供することにある。
【課題を解決するための手段】
【０００５】
請求項１記載の発明は、車両（Ｍ）の運転者の操作または車両の司令部（１３０）の指示に応じて前記車両の少なくとも一部を作動させるための制御システム（１００）の設計支援システム（５００）であって、前記車両は、複数の作動部と、前記複数の作動部を制御するための制御システムとを有しており、前記複数の作動部のうちの任意の作動部は、前記運転者の操作または前記司令部の指示に基づいて作動するように設定されており、前記制御システムは、少なくとも前記任意の作動部に関する複数の機能部であって、前記作動部の作動に関し直列の関係にある複数の機能部を有しており、前記複数の機能部は、前記複数の機能部の間で前記作動部の作動のための信号の送り側となる第１機能部（１００）と、前記信号の受け側となる第２機能部（２２０）と、を含むものであって、当該設計支援システムは、前記第１機能部から前記第２機能部へ供給される信号に関する検証結果を取得する取得部（５１０）と、前記第１機能部から前記第２機能部へ供給される信号に関する前記第１機能部側の第１の検証結果の入力の有無と、上記信号に関する前記第２機能部側の第２の検証結果の入力の有無と、の少なくとも一方を報知可能とする報知部（５５０）と、を備えることを特徴とする設計支援システムである。
請求項１によれば、本発明によって、設計者或いは設計支援システムのユーザーは、少なくとも検証が要求されていることを知ることができ、検証作業の効率向上が図れる。
【０００６】
請求項２記載の発明は、前記機能部に関する検証のための条件を含む情報を記憶する記憶部（５２０）を備え、前記報知部は、前記検証のための条件を含む情報を表示手段に表示させることを特徴とする。
請求項２によれば、検証の基準にすべき条件等を容易に確認できるので、検証作業の効率向上が図れる。
【０００７】
請求項３記載の発明は、前記報知部は、前記第１の検証結果と前記第２の検証結果とに基づいた前記第１機能部と前記第２機能部に関する設計段階を報知することを特徴とする。
請求項３によれば、双方の検証が終わっているか否かを知ることができる。また双方の検証が終わった場合に、その結果が一致しているか否かを知ることができる。そして、一致したことを可視化したことによって、機能安全の検証の結果を容易に共有することができ、検証作業の効率向上が図れる。
【０００８】
請求項４記載の発明は、車両（Ｍ）の運転者の操作または車両の司令部（１３０）の指示に応じて前記車両の少なくとも一部を作動させるための制御システム（１００）の設計支援システム（５００）であって、前記車両は、複数の作動部と、前記複数の作動部を制御するための制御システムとを有しており、前記複数の可動部のうちの任意の作動部は、前記運転者の操作または前記司令部の指示に基づいて作動するように設定されており、前記制御システムは、少なくとも前記任意の作動部に関する複数の機能部であって、前記作動部の作動に関し直列の関係にある複数の機能部を有しており、前記複数の機能部は、前記複数の機能部の間で前記作動部の作動のための信号の送り側となる第１機能部（１００）と、前記信号の受け側となる第２機能部（２２０）と、を含むものであって、当該設計支援システムは、少なくとも、前記第１機能部に関する情報と、前記第２機能部に関する情報と、前記第１機能部から前記第２機能部へ供給される信号に関する情報と、少なくとも前記第１機能部または前記第２機能部の設計または検証に関わる人に関する情報と、を表示手段に表示させる報知部（５５０）を備えることを特徴とする設計支援システムである。
請求項４によれば、検証結果を共有すべき相手の情報が容易に確認できるので、検証作業の効率向上が図れる。
【０００９】
請求項５記載の発明は、前記機能部に関する検証のための条件を含む情報を記憶する記憶部（５２０）を備え、前記報知部は、前記検証のための条件を含む情報を表示手段に表示させることを特徴とする。
請求項５によれば、検証の基準にすべき条件等を容易に確認でき、共有すべき相手との情報の共有の精度があがり、検証作業の効率向上が図れる。
【００１０】
請求項６記載の発明は、前記設計支援システムは、前記機能部に関する検証結果を取得する取得部（５１０）を備え、前記報知部は、前記第１機能部から前記第２機能部へ供給される信号に関する前記第１機能部側の第１の検証結果の入力の有無と、上記信号に関する前記第２機能部側の第２の検証結果の入力の有無と、の少なくとも一方を報知可能とすることを特徴とする。
請求項６によれば、本発明によって、設計者或いは設計支援システムのユーザーは、少なくとも検証が要求されていることを知ることができ、検証作業の効率向上が図れる。
【００１１】
請求項７記載の発明は、ユーザーの操作に応じて駆動部を駆動させる制御システム（１００）を設計対象とし、当該制御システムに関する機能安全の設計を支援する設計支援システム（５００）であって、当該制御システムは、複数の機能部を含み、前記複数の機能部には前記駆動部を駆動させるための処理が当該処理の流れに従って機能分割されて割り付けられており、前記複数の機能部のそれぞれが、それぞれに割り付けられた処理を実施して前記駆動部を駆動させるものであり、前記複数の機能部のうち、前記処理に係る指令を送出する第１機能部（１００）と、前記第１機能部から送出された指令を受ける第２機能部（２２０）とについて、前記第１機能部と前記第２機能部との間の前記指令に係る信号が、前記機能分割に従い決定され、前記第２機能部の機能と当該信号との関係が前記機能安全の要求度を満足することを検証する検証部（５１０）を備える設計支援システムである。
請求項７によれば、本発明によって、設計者或いは設計支援システムのユーザーは、少なくとも検証が要求されていることを知ることができ、検証作業の効率向上が図れる。サービスロボットなどへの適用も可能である。
【００１２】
請求項８記載の発明は、ユーザーの操作に応じて駆動部を駆動させる制御システムを設計対象とし、当該制御システムに関する機能安全の設計を支援する設計支援方法であって、当該制御システムは、複数の機能部を含み、前記複数の機能部には前記駆動部を駆動させるための処理が当該処理の流れに従って機能分割されて割り付けられており、前記複数の機能部のそれぞれが、それぞれに割り付けられた処理を実施して前記駆動部を駆動させるものであり、前記複数の機能部のうち、前記処理に係る指令を送出する第１機能部と、前記第１機能部から送出された指令を受ける第２機能部とについて、前記第１機能部と前記第２機能部との間の前記指令に係る信号が、前記機能分割に従い決定され、前記第２機能部の機能と当該信号との関係が前記機能安全の要求度を満足することを検証する過程を含む設計支援方法である。
請求項８によれば、本発明の設計支援方法によって、設計者或いは設計支援システムのユーザーは、少なくとも検証が要求されていることを知ることができ、検証作業の効率向上が図れる。
【００１３】
請求項９記載の発明は、ユーザーの操作に応じて駆動部を駆動させる制御システムを設計対象とし、当該制御システムに関する機能安全の設計を支援する設計支援システムのコンピュータに実行させるためのプログラムであって、設計を支援する対象の制御システムは、複数の機能部を含み、前記複数の機能部には前記駆動部を駆動させるための処理が当該処理の流れに従って機能分割されて割り付けられており、前記複数の機能部のそれぞれが、それぞれに割り付けられた処理を実施して前記駆動部を駆動させるものであり、前記複数の機能部のうち、前記処理に係る指令を送出する第１機能部と、前記第１機能部から送出された指令を受ける第２機能部とについて、前記第１機能部と前記第２機能部との間の前記指令に係る信号が、前記機能分割に従い決定され、前記第２機能部の機能と当該信号との関係が前記機能安全の要求度を満足することを検証するステップを含むプログラムである。
請求項９によれば、本発明のプログラムによって、設計者或いは設計支援システムのユーザーは、少なくとも検証が要求されていることを知ることができ、検証作業の効率向上が図れる。
【発明の効果】
【００１４】
請求項１から請求項９に記載の発明によれば、上記の構成を備えることにより、複数の要素に機能分割された制御システムの設計の検証を、効率よく実施することを可能にする設計支援システム、設計支援方法、及びプログラムを提供することができる。
【図面の簡単な説明】
【００１５】
【図１】実施形態における設計支援システムを適用して設計する車両の一例を示す図である。
【図２】実施形態に係る車両制御システムを中心とした機能構成図である。
【図３】実施形態に係る設計支援システムを中心とした機能構成図である。
【図４】実施形態に係る制御系全体の標準アーキテクチャを説明するための図である。
【図５Ａ】実施形態の完成車全体の機能安全プロセスの概要について説明するための図である。
【図５Ｂ】実施形態の完成車全体の機能安全プロセスに係る設計の流れと、それを支援する処理を示すフローチャートである。
【図６】実施形態の基礎アーキテクチャを説明するための図である。
【図７】実施形態に係る基礎アーキテクチャを作成する処理の手順を示すフローチャートである。
【図８】実施形態の初期アーキテクチャを説明するための図である。
【図９】実施形態に係る初期アーキテクチャを作成する処理の手順を示すフローチャートである。
【図１０】実施形態のハザードの影響の分析について説明するための図である。
【図１１】実施形態に係るハザードの影響を分析する処理の手順を示すフローチャートである。
【図１２】実施形態に係るコンセプト設計と影響分析を評価する処理の手順を示すフローチャートである。
【図１３】実施形態のシステム間の影響分析について説明するための図である。
【図１４】実施形態のシステム間のインタフェースに割り当てられたＡＳＩＬを確認するための方法について説明するための図である。
【図１５】実施形態に係るシステム間の機能安全要求の整合の検証を支援する処理の手順を示すフローチャートである。
【図１６】実施形態に係るシステム間の機能安全要求の整合の検証を支援する処理について説明するための図である。
【図１７】実施形態に係るシステム間の機能安全要求の整合の検証を支援する処理について説明するための図である。
【図１８】実施形態の機能安全要求情報ＤＢの一例を示す図である。
【図１９】実施形態の設計支援システムが生成した情報を表示する画面の一例について説明するための図である。
【図２０】実施形態の設計支援システムが生成した情報を表示する画面の一例について説明するための図である。
【図２１】実施形態の実施形態のハザードの影響の分析について説明するための図である。
【図２２】ハザードの影響伝達の仕組みについて説明するための図である。
【図２３】ハザードの発生を軽減するための仕組みについて説明するための図である。
【図２４】実施形態のアイテムの範囲を示す図である。
【図２５】国際規格ＩＳＯ２６２６２の全体を示す図である。
【発明を実施するための形態】
【００１６】
以下、図面を参照し、本発明の設計支援システム、設計支援方法、及びプログラムの実施形態について説明する。
【００１７】
＜設計支援システムの概要と実施形態の説明に用いる各種用語について＞
最初に、設計支援システムの概要と、以下の実施形態の説明に用いる各種用語について説明する。
実施形態に係る設計支援システムは、下記のような制御システムの設計を支援する。その制御システムは、例えば、人の操作又は外部からの指令（又は命令）に基づいて、若しくは、指令部からの指令（又は命令）により、各種作動部が作動するように制御するものであり、例えば、可動部を動かすための駆動部を制御するもの、移動体の移動を制御するものなどである。上記の移動体には、人が搭乗してもよく、搬送車のように人が搭乗しなくてもよい。その移動体は、人の操縦により移動するものであってもよく、判断機能を有し自律して移動するものであってもよい。例えば、自動車、飛行機、歩行型のロボットなどは、上記の移動体の一例である。なお、実施形態に係る設計支援システムは、上記のような移動体の制御システムの機能安全の設計に適用可能なものである。
【００１８】
実施形態に係るアイテムとは、移動体を移動させるなどの目的で、電気的・電子的な制御を実行するシステム又はシステムの集合体（システム群）である。例えば、アイテムは、移動体全体に係る制御システムに対応するものであってもよく、その移動体全体に係る制御システムの一部を構成するものであってもよい。上記のアイテムは、例えば、複数のシステムに分割されていて、その複数のシステムが互いに協調して作用するものであってもよい。なお、以下に示す実施形態の説明における移動体として、自動車を例示して説明する。この場合のアイテムは、「車両制御システム」に相当する。
【００１９】
実施形態に係るメカニズムとは、移動体のアイテムが作用して、その移動体の外部環境に対して影響を与え得るものを総称する。エンジン、モータ、ソレノイドなどのアクチュエータは、機械的な作用により当該移動体の外部に影響を与え得るものの一例である。また、移動体に搭載された発光体、つまり、前照灯、車幅灯などは、電気的な作用により当該移動体の外部に影響を与え得るものの一例である。なお、メカニズムには、上記の直接的に作用するものの他に間接的に作用するものも含まれることがある。例えば、移動体の一部又は全部についてそれを数値化した制御モデルを定め、このような制御モデルを用いて移動体を制御することがある。このように制御システムが移動体を制御するために参照する各種制御モデルは、例えば、論理的な作用により間接的に当該移動体の外部に影響を与え得るものの一例である。
【００２０】
実施形態に係るコンセプト設計段階とは、例えば、設計対象のシステムが実現する機能を、要素に分割する設計を実施する段階のことである。
【００２１】
実施形態に係るハザードとは、国際規格ＩＳＯ２６２６２の定義に準じる。国際規格ＩＳＯ２６２６２によれば、要するに、上記のアイテムの機能不全の振る舞いにより引き起こされる人の健康に対する身体的な障害または被害になりうる原因のことである。なお、以下の説明において、国際規格ＩＳＯ２６２６２：２０１１（Road Vehicles-Functional Safety）のことを単に「国際規格」という。図２５は、国際規格の全体を示す図である。
【００２２】
実施形態におけるＡＳＩＬ(Automotive Safety Integrity Level)とは、国際規格により規定された自動車用安全度水準のことである。国際規格における自動車用安全度水準は、管理すべき水準が「ASIL A」、「ASIL B」、「ASIL C」、「ASIL D」の４つに階層分けされている。その内、「ASIL A」が最も低い安全度水準に、「ASIL D」が最も高い安全度水準に対応付けられている。なお、上記の国際規格に対応するＪＩＳ  Ｃ  ０５０８−４：２０１２は、実施形態の技術に関連する規定の一例である。なお、自動車（車両）以外の移動体等の設計を対象にする場合には、実施形態におけるＡＳＩＬを、自動車（車両）以外のものに適用される安全度水準（ＳＩＬ：Safety Integrity Level）に読み替えてもよい。
【００２３】
ＱＭ（Quality Management）とは、上記のＡＳＩＬを用いて管理すべき水準の内、その最も低い水準の「ASIL A」よりも低い水準のことである。この水準に割り付けられたものは、例えば、国際規格では要件管理下の対象として扱うものとはせずに、通常の品質管理で管理されている。
【００２４】
システムの担当者（ＰＩＣ１からＰＩＣ３）とは、上記の各システムの設計をそれぞれ担当する担当者のことである。
【００２５】
プロセス管理者ＰＭとは、上記の制御システム全体についてのコンセプト設計段階の設計をする者のことである。
【００２６】
＜設計対象の移動体（車両）＞
次に、実施形態における設計支援システムを移動体（車両）の設計に適用する事例について説明する。図１は、実施形態における設計支援システムを適用して設計する車両（以下、自車両Ｍと称する）の一例を示す図である。自車両Ｍには、車両制御システム１００が搭載される。自車両Ｍは、例えば、二輪や三輪、四輪等の自動車であり、ディーゼルエンジンやガソリンエンジン等の内燃機関を動力源とした自動車や、電動機を動力源とした電気自動車、内燃機関および電動機を兼ね備えたハイブリッド自動車等を含む。電気自動車は、例えば、二次電池、水素燃料電池、金属燃料電池、アルコール燃料電池等の電池により放電される電力を使用して駆動される。
【００２７】
図１に示すように、自車両Ｍには、ファインダ２０−１から２０−７、レーダ３０−１から３０−６、およびカメラ４０等のセンサと、ナビゲーション装置５０と、車両制御システム１００とが搭載される。上記ファインダ２０−１から２０−７、レーダ３０−１から３０−６、およびカメラ４０等のセンサは、例えば、後述する検知デバイスＤＤを構成している。
【００２８】
ファインダ２０−１から２０−７は、例えば、照射光に対する散乱光を測定し、対象までの距離を測定するＬＩＤＡＲ（Light Detection and Ranging、或いはLaser Imaging Detection and Ranging）である。例えば、上述したファインダ２０−１から２０−６のそれぞれは、例えば、水平方向に関して１５０度程度の検出領域を有している。また、ファインダ２０−７は、ルーフ等に取り付けられる。ファインダ２０−７は、例えば、水平方向に関して３６０度の検出領域を有している。
【００２９】
レーダ３０−１から３０−６は、例えばＦＭ−ＣＷ（Frequency Modulated Continuous Wave）方式によって自車両Ｍを基準に定められた所定の範囲に存在する物体を検出するミリ波レーダである。
【００３０】
以下、ファインダ２０−１から２０−７を特段区別しない場合は、単に「ファインダ２０」と記載し、レーダ３０−１から３０−６を特段区別しない場合は、単に「レーダ３０」と記載する。
【００３１】
カメラ４０は、例えば、ＣＣＤ（Charge Coupled Device）やＣＭＯＳ（Complementary Metal Oxide Semiconductor）等の固体撮像素子を利用したデジタルカメラである。カメラ４０は、フロントウインドシールド上部やルームミラー裏面等に取り付けられる。カメラ４０は、例えば、周期的に繰り返し自車両Ｍの前方を撮像する。カメラ４０は、複数のカメラを含むステレオカメラであってもよい。
【００３２】
なお、図１に示す構成はあくまで一例であり、構成の一部が省略されてもよいし、更に別の構成が追加されてもよい。
【００３３】
図２は、実施形態に係る車両制御システム１００を中心とした機能構成図である。自車両Ｍには、車両制御システム１００（ＣＯＮＴ１００）と、走行駆動力出力装置２００と、車両安定性制御装置２２０（ＶＳＡＳ２２０）、ブレーキ装置２３０（ＥＳＢＳ２３０）と、灯具２４０と、表示装置２４５（ＩＰＳ２４５）と、ステアリング装置２５０（ＥＯＳＳ２５０）と、蓄電池管理装置２７０（ＢＭＳ２７０）と、運行制御装置２８０（ＣＣＳ２８０）と、ＳＷセンサ２９０（ＳＷＳＥＮＳ２９０）とが搭載される。これらの装置や機器は、ＣＡＮ（Controller Area Network）通信線等の多重通信線やシリアル通信線、無線通信網等によって互いに接続される。
なお、特許請求の範囲における車両制御システムは、「車両制御システム１００」のみを指しているのではなく、車両制御システム１００以外の構成（後述する検知デバイスＤＤなど）を含んでもよい。
【００３４】
［ＳＷセンサ］
ＳＷセンサ２９０は、ファインダ２０、レーダ３０、およびカメラ４０などを含む検知デバイスＤＤと、ナビゲーション装置５０と、通信装置５５と、車両センサ６０と、アクセルペダル７０と、アクセル開度センサ７１と、ブレーキペダル８０と、ブレーキ踏量センサ８１と、自動運転切替スイッチ９１と、を含む。
【００３５】
ナビゲーション装置５０は、ＧＮＳＳ（Global Navigation Satellite System）受信機や地図情報（ナビ地図）、ユーザインターフェースとして機能するタッチパネル式表示装置、スピーカ、マイク等を有する。ナビゲーション装置５０は、ＧＮＳＳ受信機によって自車両Ｍの位置を特定し、その位置から搭乗者によって指定された目的地までの経路を導出する。ナビゲーション装置５０により導出された経路は、車両制御システム１００に提供される。自車両Ｍの位置は、車両センサ６０の出力を利用したＩＮＳ（Inertial Navigation System）によって特定または補完されてもよい。また、ナビゲーション装置５０は、目的地に至る経路について音声やナビ表示によって案内を行う。なお、自車両Ｍの位置を特定するための構成は、ナビゲーション装置５０とは独立して設けられてもよい。また、ナビゲーション装置５０は、例えば、搭乗者の保有するスマートフォンやタブレット端末等の端末装置の機能によって実現されてもよい。この場合、端末装置と車両制御システム１００との間で、無線または有線による通信によって情報の送受信が行われる。
【００３６】
通信装置５５は、例えば、セルラー網やＷｉ−Ｆｉ網、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＤＳＲＣ（Dedicated Short Range Communication）などを利用した無線通信を行う。
【００３７】
車両センサ６０は、車速を検出する車速センサ、加速度を検出する加速度センサ、鉛直軸回りの角速度を検出するヨーレートセンサ、自車両Ｍの向きを検出する方位センサ等を含む。
【００３８】
アクセルペダル７０は、車両乗員による加速指示（或いは戻し操作による減速指示）を受け付けるための操作子である。アクセル開度センサ７１は、アクセルペダル７０の踏み込み量を検出し、踏み込み量を示すアクセル開度信号を車両制御システム１００に出力する。なお、車両制御システム１００に出力するのに代えて、走行駆動力出力装置２００、ステアリング装置２５０、またはブレーキ装置２３０に直接出力することがあってもよい。以下に説明する他の運転操作系の構成についても同様である。
【００３９】
ブレーキペダル８０は、車両乗員による減速指示を受け付けるための操作子である。ブレーキ踏量センサ８１は、ブレーキペダル８０の踏み込み量（或いは踏み込み力）を検出し、検出結果を示すブレーキ信号を車両制御システム１００に出力する。
【００４０】
自動運転切替スイッチ９１は、車両の運転を制御する状態を、運転者が主体となって運転するモードと、車両に搭載された制御装置が主体となって運転する自動運転モードとを切替える操作を受け付けるための操作子である。
【００４１】
［車両制御システム］
続いて、車両制御システム１００（制御システム）について説明する。
車両制御システム１００は、ＨＭＩ制御部１１０と、走行制御部１２０と、自動運転制御部１３０とを備え、ＣＰＵ（Central Processing Unit）などのプロセッサがプログラム（ソフトウェア）を実行することで実現される。また、以下に説明する機能（処理）のうち一部または全部は、ＬＳＩ（Large Scale Integration）やＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）などのハードウェアによって実現されてもよいし、ソフトウェアとハードウェアの協働によって実現されてもよい。
【００４２】
ＨＭＩ制御部１１０は、自車両Ｍの乗員に対して表示装置２４５等を介して、自車両Ｍの状態等に関する各種情報を提示すると共に、乗員による入力操作を受け付ける。ＨＭＩ制御部１１０は、各種表示装置、スピーカ、ブザー、タッチパネル、スイッチ、キーなどを含むものであってもよい。
【００４３】
走行制御部１２０は、自動運転制御部１３０によって生成された目標軌道を、予定の時刻通りに自車両Ｍが通過するように、走行駆動力出力装置２００、車両安定性制御装置２２０、ブレーキ装置２３０、およびステアリング装置２５０等を制御する。走行制御部１２０は、周囲の状況が比較的暗い場合に、灯具２４０を点灯させるようにその点灯状態を制御する。
【００４４】
自動運転制御部１３０は、カメラ、レーダ装置、およびファインダ等の検知デバイスDD、スイッチ、センサなどからの情報（スイッチ情報、センサ情報）に基づいて、自車両Ｍの周辺の物体の位置、および速度、加速度等の状態を認識する。自動運転制御部１３０は、ステアリング装置２５０からのステアリング情報により、自車両の操舵輪Ｗ２の制御状態を取得する。自動運転制御部１３０は、蓄電池管理装置２７０からの情報（蓄電池制御状態）により蓄電地の蓄電状態を取得する。自動運転制御部１３０は、運行制御装置２８０と連携して、自車両Ｍの走行を制御する。
【００４５】
自動運転制御部１３０は、例えば、自車両Ｍが走行している車線（走行車線）、並びに走行車線に対する自車両Ｍの相対位置および姿勢を認識する。自車位置認識部１２２は、例えば、高精度地図情報から得られる道路区画線のパターン（例えば実線と破線の配列）と、カメラによって撮像された画像から認識される自車両Ｍの周辺の道路区画線のパターンとを比較することで、走行車線を認識する。そして、自動運転制御部１３０は、例えば、走行車線に対する自車両Ｍの位置や姿勢を認識し、それらに基づいて走行する推奨車線を決定して目標車線情報を生成する。
【００４６】
自動運転制御部１３０は、決定された目標車線を走行するように、かつ、認識された自車両Ｍの周辺状況に対応できるように、自車両Ｍが将来走行する目標軌道を生成するとともに、運行制御装置２８０が利用する制御モデルを逐次更新する。
【００４７】
続いて、走行駆動力出力装置２００、車両安定性制御装置２２０（ＶＳＡＳ２２０）、ブレーキ装置２３０（ＥＬＢＳ２３０）と、灯具２４０と、表示装置２４５（ＩＰＳ２４５）と、ステアリング装置２５０（ＥＰＳＳ２５０）と、蓄電池管理装置２７０（ＢＭＳ２７０）と、運行制御装置２８０（ＣＣＳ２８０）とについて説明する。
【００４８】
［走行駆動力出力装置］
走行駆動力出力装置２００は、車両が走行するための走行駆動力（トルク）を駆動輪Ｗ１に出力する。走行駆動力出力装置２００は、例えば、自車両Ｍがエンジンを動力源とした自動車である場合、自車両Ｍが電動機を動力源とした電気自動車である場合、或いは、自車両Ｍがハイブリッド自動車である場合等が挙げられる。
【００４９】
例えば、自車両Ｍが内燃機関を動力源とした自動車である場合、エンジン、エンジンを制御するエンジンＥＣＵ（Electronic Control Unit）等を含むエンジン装置２６０（ＥＮＧＳ２６０）、ギアを含む変速機２６５（ＴＭＳ２６５）等を備える。上記の場合、エンジン装置２６０のエンジンＥＣＵは、後述する走行制御部１２０から入力される情報に従って、エンジンのスロットル開度を制御することで、エンジンからエンジントルク（Ｆ５）を出力する。エンジンＥＣＵは、変速機２６５のシフト段等を調整する。変速機２６５は、エンジントルクとギア比に基づいて決定される駆動力、つまり、駆動輪Ｗ１を駆動するための駆動力（Ｆ４）を出力する。なお、エンジンは、作動部の一例である。
【００５０】
或いは、自車両Ｍが電動機を動力源とした電気自動車である場合、走行用モータおよび当該走行用モータを制御するモータＥＣＵを備える。上記の場合、モータＥＣＵは、走行制御部１２０から入力される情報に従って、走行用モータに与えるＰＷＭ(Pulse Width Modulation)信号のデューティ比を調整する。なお、走行用モータは、作動部の一例である。
【００５１】
また、或いは、自車両Ｍがハイブリッド自動車である場合、エンジン、ギア、蓄電池、走行用モータ（モータ）およびこれらを制御するハイブリッドシステムＥＣＵを備え、上記の各部を含むハイブリッドシステム２１０（ＨＳ２１０）を成す。上記の場合、走行駆動力出力装置２００がエンジンおよび走行用モータを含む場合、ハイブリッドシステムＥＣＵは、走行制御部１２０から入力される情報に従って、エンジンおよび走行用モータを協調させることにより駆動輪Ｗ１を駆動する駆動力（Ｆ１：走行駆動力）を制御する。なお、エンジン、ギア、蓄電池、走行用モータ（モータ）は、作動部の一例である。
【００５２】
［車両安定性制御装置］
車両安定性制御装置２２０は、例えば、車両安定性制御ＥＣＵと、車両の安定性を制御するための油圧制御ユニットとを備える。油圧制御ユニットは、例えば、走行する車両が横滑りしたときの制動力を調整することにより、車両の安定性を確保する。車両安定性制御ＥＣＵは、車両制御システム１００から入力される情報、或いはブレーキペダルから入力されるブレーキペダルの踏込量などの情報に従ってアクチュエータ（油圧制御ユニット）を操作することで、駆動輪Ｗ１の制動力（Ｆ２）を調整する。なお、油圧制御ユニットは、作動部の一例である。
【００５３】
［ブレーキ装置］
ブレーキ装置２３０は、例えば、ブレーキＥＣＵと、電動モータとを備える。電動モータは、例えば、走行する車両の車輪から受ける動力を電気エネルギーに変換することにより、車輪に対する制動力を生成する。ブレーキＥＣＵは、車両制御システム１００から入力される情報、或いはブレーキペダルから入力されるブレーキペダルの踏込量などの情報に従って電動モータを回生状態にすることで、駆動輪Ｗ１を制動させるように、車輪の制動力（Ｆ３）を調整する。なお、電動モータは、作動部の一例である。
【００５４】
［灯具］
灯具２４０は、例えば、前照灯（ヘッドライト）、ポジション灯（車幅灯）等を備える。灯具２４０は、車両制御システム１００から入力される情報に従って前照灯、ポジション灯等の点灯状態を制御することで、夜間又は薄明りの状況のもとで走行可能な状態にする。なお、自車両Ｍの周囲の明るさ等に応じて前照灯等の点灯状態を調整するオートライト機能が知られている。オートライト機能を有する車両は、オートライト機能を有効または無効にするためのオートライトモード切替スイッチを備えていてもよい。例えば、オートライトモード切替スイッチにより、オートライト機能が有効化されている場合、自車両Ｍの周囲の明るさが所定値以下になっていると前照灯を点灯し、同明るさが所定値を超えていると前照灯を消灯する。なお、前照灯、ポジション灯等は、電気的な作動部の一例である。
【００５５】
［表示装置］
表示装置２４５は、例えば、インストルメントパネルの各部、助手席や後部座席に対向する任意の箇所などに取り付けられる、ＬＣＤ（Liquid Crystal Display）や有機ＥＬ（Electroluminescence）などの表示部を含む。また、表示装置２４５は、フロントウインドシールドやその他のウインドウに画像を投影するＨＵＤ（Head Up Display）であってもよい。なお、表示部とＨＵＤは、電気的な作動部の一例である。
【００５６】
［ステアリング装置］
ステアリング装置２５０は、例えば、ステアリングＥＣＵと、ステアリングモータとを備える。ステアリングモータは、例えば、ラックアンドピニオン機構に力を作用させて操舵輪Ｗ２の向きを変更する。ステアリングＥＣＵは、車両制御システム１００から入力される情報、或いは入力されるステアリング操舵角またはステアリングトルクの情報に従ってステアリングモータを駆動し、操舵輪Ｗ２の向きを変更させる。なお、ステアリングモータは、作動部の一例である。
【００５７】
［蓄電地制御装置］
蓄電池管理装置２７０は、例えば、蓄電地制御ＥＣＵと、変換器とを備える。変換器は、例えば、発電機により発電された電力、又は、モータにより回生された電力を変換して、蓄電池を充電させるための電力を生成する。蓄電地制御ＥＣＵは、車両制御システム１００から入力される情報、或いは入力される蓄電地の充電量の情報に従って変換量を制御する。なお、蓄電池は、電気的な作動部の一例である。
【００５８】
［運行制御装置］
運行制御装置２８０は、例えば、運行制御ＥＣＵと、制御モデルとを備える。制御モデルは、例えば、自動運転制御において、自車両Ｍの走行中の状態を数値化したデータの集合体である。運行制御ＥＣＵは、車両制御システム１００から入力される目標車速要求、加速割合要求等を含む情報に従って、制御目標量を決定する制御モデルを更新する。運行制御ＥＣＵは、ギアを制御するための要求を生成する。なお、運行制御装置２８０は、車両制御システム１００の一部として構成されていてもよい。なお、制御モデルは、電気的な作動部の一例である。
【００５９】
［その他の装置］
自車両Ｍは、図２に示す各構成の他に、ワイパー装置等の図示しない装置を備えるものであってもよい。
【００６０】
＜設計支援システム＞
（第１の実施形態）
次に、実施形態の設計支援システム５００について説明する。
【００６１】
図３は、実施形態に係る設計支援システム５００を中心とした機能構成図である。
設計支援システム５００は、ＬＡＮ、インターネット、公衆網などのネットワークＮＷを介して端末装置６００−１、６００−２、６００−３、６００−４等に接続される。例えば、端末装置６００−１、６００−２、６００−３は、システムの担当者ＰＩＣ１、ＰＩＣ２、ＰＩＣ３等によって操作され、６００−４は、プロセス管理者ＰＭによって操作されるものとする。以下、端末装置６００−１から６００−４を特段区別しない場合は、単に「端末装置６００」と記載し、システムの担当者ＰＩＣ１からＰＩＣ３を特に区別しない場合は、単に「システムの担当者」等と記載する。端末装置６００は、パーソナルコンピュータ、携帯型の端末装置等のコンピュータである。例えば、自車両Ｍに関するシステム設計のプロセス管理者ＰＭ、自車両Ｍに関する各システムの設計者などのユーザーが端末装置６００を操作する。端末装置６００は、プロセス管理者ＰＭ、システムの担当者等の操作を検出して、それを設計支援システム５００に通知し、それに対する設計支援システム５００からの応答を受けて、端末装置６００の表示部（表示手段）に表示する。これにより各ユーザーは、目的に応じて、設計支援システム５００が提供する設計支援に関するサービスを利用することができる。そのサービスの詳細について後述する。
【００６２】
設計支援システム５００は、制御部５１０と、記憶部５２０と、通信部５３０と、情報取得部５４０と、報知部５５０とを備える。
【００６３】
制御部５１０は、基礎アーキテクチャ作成部５１１と、初期アーキテクチャ作成部５１２と、影響分析部５１３と、機能安全要求整合判定部５１４と、標準アーキテクチャ更新部５１５と、詳細設計支援部５１６と、詳細設計結果検証部５１７とを備える。制御部５１０の各部の詳細は後述する。
【００６４】
記憶部５２０は、標準アーキテクチャＤＢ５２１と、基礎アーキテクチャＤＢ５２２と、初期アーキテクチャＤＢ５２３と、ハザード分析情報ＤＢ５２４と、機能安全要求情報ＤＢ５２５とを、その記憶領域に格納する。
【００６５】
標準アーキテクチャＤＢ５２１には、完成車両全体を構成するのに必要とされる一又は複数の標準アーキテクチャを示すデータが、その識別情報、登録日（作成日、更新日）、適用期間などの付加データとともに格納される。標準アーキテクチャとは、自車両Ｍの制御系を設計する際に参照され、制御系全体の設計資産として利用可能な構成を規定するものである。
【００６６】
図４は、実施形態に係る制御系全体の標準アーキテクチャを説明するための図である。
この標準アーキテクチャは、実際の車両１台分を構成する際に、車両の種別（仕様）等により択一的に選択される冗長な構成を含むものであってもよい。例えば、標準アーキテクチャＤＢ５２１に格納された標準アーキテクチャは、既に設計並びに検証されたものが含まれることがある。
【００６７】
この図４に示す標準アーキテクチャにおいて、四角形が各種「システム」に対応付けられ、楕円が各種「システム」に含まれる「機構（メカニズム）」に対応付けられる。「機構（メカニズム）」は作動部の一例である。
【００６８】
この図４に示す各種「システム」は、前述の自車両Ｍのアイテムに含まれるものである。具体的には、各種「システム」として、車両制御システム１００（ＣＯＮＴ１００）と、走行駆動力出力装置２００と、車両安定性制御装置２２０（ＶＳＡＳ２２０）、ブレーキ装置２３０（ＥＳＢＳ２３０）と、灯具２４０と、表示装置２４５（ＩＰＳ２４５）と、ステアリング装置２５０（ＥＰＳＳ２５０）と、蓄電池管理装置２７０（ＢＭＳ２７０）と、運行制御装置２８０（ＣＣＳ２８０）と、ＳＷセンサ２９０（ＳＷＳＥＮＳ２９０）とが含まれている。以下、上記の括弧内に示す表記を用いて説明する。この図４において、ＶＳＡＳ２２０と、ＥＳＢＳ２３０と、ＣＣＳ２８０とが、２つずつ記載されているが、これらは、状態などを示す信号を出力する機能と状態などを示す信号を受ける機能とを分けて示すために２つに分けて表記しているが、それぞれが一体で形成されたものである。
【００６９】
また、各種「システム」間を繋ぐインタフェースには、「情報」、「動作要求」、「機構力」のそれぞれが割り当てられている。上記の図４では、「情報」を細い矢印、「動作要求」を太い矢印、「機構力」を太い輪郭線の矢印で示す。同様に、「機構（メカニズム）」の作動により可動部（作動部）に作用する「機構力」を太い輪郭線の矢印で示す。
【００７０】
ＩＦ１からＩＦ１４は、ＣＯＮＴ１００に係るインタフェースの一例である。ＣＯＮＴ１００からの出力系インタフェース（ＩＦ１からＩＦ６と、ＩＦ１４）には、下記の通り、その役割が割り当てられている。例えば、ＣＯＮＴ１００からＨＳ２１０に向かうＩＦ１にはＨＳ２１０に対する要求駆動力が割り当てられている。ＣＯＮＴ１００からＶＳＡＳ２２０と、ＥＳＢＳ２３０と、ＩＰＳ２４５のそれぞれに向かうＩＦ２、ＩＦ３、ＩＦ５には、ＶＳＡＳ２２０と、ＥＳＢＳ２３０と、ＩＰＳ２４５とに対してＣＯＮＴ１００の制御状態を示す情報が割り当てられている。ＣＯＮＴ１００から灯具２４０に向かうＩＦ４には、灯具２４０に対する作動要求が割り当てられている。ＣＯＮＴ１００からＣＣＳ２８０に向かうＩＦ６には、ＣＣＳ２８０に対する加速減速要求とＣＯＮＴ１００の制御状態を示す情報が割り当てられている。ＣＯＮＴ１００からＥＮＧＳ２６０に向かうＩＦ１４にはＥＮＧＳ２６０に対する要求駆動力が割り当てられている。
【００７１】
ＣＯＮＴ１００の情報収集系インタフェース（ＩＦ７からＩＦ１３）には、下記の通り、その役割が割り当てられている。例えば、ＳＷＳＥＮＳ２９０からのＩＦ７にはスイッチ情報とセンサ情報が、ＥＰＳＳ２５０からのＩＦ８にはステアリング情報（検出値）が割り付けられている。ＶＳＡＳ２２０からのＩＦ９とＩＦ１０にはステアリング情報（制御目標値）と、ＶＳＡの制御状態（ＶＳＡ状態）を示す情報とがそれぞれ割り付けられている。ＢＭＳ２７０からのＩＦ１２には蓄電池の制御状態（蓄電池制御状態）に関する情報が割り付けられており、更に、ＢＭＳ２７０からは、直流１２Ｖの電力が各部に供給される。ＣＣＳ２８０からのＩＦ１３にはギア制御要求情報とＣＣＳ２８０の制御状態を示す情報とがそれぞれ割り付けられている。
【００７２】
なお、上記の各インタフェースの個数、それに割り付けられた情報は一例を示すものであり、これに制限されるものではなく、適宜追加又は変更することができる。
【００７３】
更に、この図４には、それに関連する可動部と、当該可動部に関連して想定される「ハザード」の一例を示す。「ハザード」は、図４において、２点鎖線の輪郭線を有する５角形を用いて示す。この図４に例示した駆動輪(走行輪)Ｗ１は、可動部の一例である。
【００７４】
図３に戻り、記憶部５２０の説明を続ける。
基礎アーキテクチャＤＢ５２２には、完成車両全体の構成を示す基本アーキテクチャのデータが、その識別情報、登録日（作成日、更新日）、適用製品名、適用製品識別コードなどの付加データとともに格納される。基本アーキテクチャは、標準アーキテクチャＤＢ５２１に格納された標準アーキテクチャのデータに基づいて生成される。基本アーキテクチャの詳細については後述する。
【００７５】
初期アーキテクチャＤＢ５２３には、設計初期の完成車両全体の構成（初期アーキテクチャ）を示すデータが、その識別情報、登録日（作成日、更新日）、適用製品名、適用製品識別コード、対象システム名、対象システムの担当者の担当者名（識別情報）などの付加データとともに格納される。初期アーキテクチャは、基礎アーキテクチャＤＢ５２２に格納された基本アーキテクチャのデータに基づいて生成される。初期アーキテクチャの詳細については後述する。
【００７６】
ハザード分析情報ＤＢ５２４には、想定されるハザードについてのリスクアセスメントを含むハザード分析の結果が格納される。例えば、上記の結果は、初期アーキテクチャに関連付けて格納され、初期アーキテクチャにおける各部にそれぞれ対応付けられている。
【００７７】
機能安全要求情報ＤＢ５２５には、機能安全要求に関する情報が格納される。例えば、機能安全要求に関する情報には、システム設計の担当者間で合意が形成された結果等が含まれる。なお、機能安全要求情報ＤＢ５２５の詳細については後述する。
【００７８】
通信部５３０は、ネットワークＮＷに接続され、端末装置６００からの要求を受けて、端末装置６００と通信する。通信部５３０は、制御部５１０と当該端末装置６００との通信を仲介する。
【００７９】
情報取得部５４０は、端末装置６００からの情報を取得して、取得した情報を記憶部５２０に書き込む処理、又は、取得した情報に対応する所望の処理を、制御部５１０に実施させる。例えば、情報取得部５４０が端末装置６００から取得する情報には、標準アーキテクチャＤＢ５２１、基礎アーキテクチャＤＢ５２２、初期アーキテクチャＤＢ５２３等に関する情報が含まれる。さらに、端末装置６００から取得する情報には、これらに各種情報を追加、変更、削除することなどの各種情報の操作に対応する情報などが含まれる。端末装置６００から取得する情報には、プロセス管理者ＰＭとシステムの担当者の何れかからの要求であって、各種情報の操作、閲覧などの要求に関する情報が含まれる。
【００８０】
報知部５５０は、要求又は制御に応じて、記憶部５２０に格納された各種情報を報知する。例えば、報知部５５０は、記憶部５２０に格納された標準アーキテクチャＤＢ５２１、基礎アーキテクチャＤＢ５２２、初期アーキテクチャＤＢ５２３等に格納されている各種情報を端末装置６００からの要求等に応じて閲覧可能にして、端末装置６００に送信する。
【００８１】
上記の各部を備える設計支援システム５００は、下記の各種データ（情報）を用いて、以下で説明する機能安全に係る設計を支援する。
【００８２】
例えば、本実施形態において、車両レベルの機能を複数に分割して、個々の機能に対応する複数のシステムにそれぞれ割り付けた後に、各システムの設計を開発するという設計手法に機能安全プロセスを適用させた事例について説明する。その事例は、車両レベルのシステムに関するコンセプト設計段階に適用させたものである。
【００８３】
図５Ａは、実施形態の完成車全体の機能安全プロセスの概要について説明するための図である。
【００８４】
プロセス管理者ＰＭと各システムの担当者は、連携して完成車全体の機能安全活動を実施する。例えば、プロセス管理者ＰＭは、各システムにおける機能安全活動の進捗を管理し、完成車全体の機能安全活動を実施する。また、各システムの担当者は、自システムのアイテムを機能安全活動の対象範囲としてプロセス（２）から（４）、プロセス（６）を実施する。なお、プロセス管理者ＰＭは、必要に応じてプロセス（５）を実施して、完成車全体の機能安全活動の標準アーキテクチャ等を見直して更新する。
【００８５】
図５Ｂは、実施形態の完成車全体の機能安全プロセスに係る設計の流れと、それを支援する処理を示すフローチャートである。この図５Ｂは、完成車全体の機能安全プロセスに係る設計を、プロセス（１）から(６)の各プロセスに分けて実施する事例の一例を示すものである。システムの担当者とプロセス管理者ＰＭは、例えば、以下に示すプロセス（１）から（６の手順に従い、機能安全活動に沿った設計を推進する。システムの担当者とプロセス管理者ＰＭは、例えば、下記のように設計支援システム５００を利用して機能安全活動に沿った設計を推進してもよい。
【００８６】
プロセス（１）：設計支援システム５００は、プロセス管理者ＰＭの管理の元で、設計対象の開発車両のアイテムの基礎アーキテクチャを作成し、それを配布する（ステップＳＡ１０）。
例えば、設計支援システム５００は、端末装置６００を介して当該プロセス管理者ＰＭに標準アーキテクチャを提示する。当該プロセス管理者ＰＭによって開発車両のアイテムについての基礎アーキテクチャが決定され、それが端末装置６００を介して設計支援システム５００に登録される。設計支援システム５００は、決定された基礎アーキテクチャを受けて、各システムの担当者に配布する。
【００８７】
プロセス（２）：設計支援システム５００は、例えば、システムの担当者の管理の元で、初期アーキテクチャを作成する（ステップＳＡ２０）。
【００８８】
プロセス（３）：設計支援システム５００は、ハザードの影響を分析する（ステップＳＡ３０）。なお、設計支援システム５００は、システムの担当者によるハザードの影響分析の結果を取得してもよい。
【００８９】
プロセス（４）：設計支援システム５００は、システム間の機能安全要求の整合の検証を支援する（ステップＳＡ４０）。
【００９０】
プロセス（５）：設計支援システム５００は、プロセス管理者ＰＭによる標準アーキテクチャの更新要求に対し、それを実施する（ステップＳＡ５０）。
【００９１】
プロセス（６）：設計支援システム５００は、システムの担当者による国際規格におけるＰＡＲＴ４システムレベルの開発以降の機能安全活動の実施を支援する（ステップＳＡ６０）。
【００９２】
続いて、上記のプロセス（１）から(６)の詳細について順に説明する。
【００９３】
［プロセス（１）］
上記のプロセス（１）における基礎アーキテクチャを作成する処理（ステップＳＡ１０）について説明する。図６は、実施形態の基礎アーキテクチャを説明するための図である。
前述の図４に示した標準アーキテクチャのように、完成車両１台分を超える冗長な構成がその標準アーキテクチャに含まれる場合がある。例えば、図４に示した標準アーキテクチャの走行駆動力出力装置２００は、冗長な構成を含む構成の一例である。この場合、冗長な構成が含まれないように択一的に選択して、図６に示すような基本アーキテクチャを生成する。図６に示す「×印」を付した構成は、選択しなかったシステムとそれに関係するインタフェース等である。
【００９４】
図７は、実施形態に係る基礎アーキテクチャを作成する処理の手順を示すフローチャートである。
【００９５】
まず、基礎アーキテクチャ作成部５１１は、標準アーキテクチャＤＢ５２１に格納された１又は複数の標準アーキテクチャの中に、所望の標準アーキテクチャが有るか否かを判定する（ステップＳＡ１１）。ステップＳＡ１１の判定の結果により、所望の標準アーキテクチャが有る場合には、基礎アーキテクチャ作成部５１１は、処理をステップＳＡ１３に進める。ステップＳＡ１１の判定の結果により、所望の標準アーキテクチャが無い場合には、基礎アーキテクチャ作成部５１１は、新たに標準アーキテクチャを生成して標準アーキテクチャＤＢ５２１に登録する（ステップＳＡ１２）。
【００９６】
次に、基礎アーキテクチャ作成部５１１は、標準アーキテクチャＤＢ５２１に登録されている標準アーキテクチャの内から所望の標準アーキテクチャを選択し、選択した標準アーキテクチャに含まれる１又は複数のシステムの内から必要とされると判定されたシステムを抽出する（ステップＳＡ１３）。
【００９７】
次に、基礎アーキテクチャ作成部５１１は、抽出されたシステムに基づいて生成されたアーキテクチャを基礎アーキテクチャとして扱い、管理のための情報を付与して、基礎アーキテクチャＤＢに登録する（ステップＳＡ１４）。なお、抽出されなかったシステム等は、実質的に標準アーキテクチャの構成から削除されたものと同様の位置付けになる。
【００９８】
次に、基礎アーキテクチャ作成部５１１は、生成された基礎アーキテクチャを、基礎アーキテクチャに関連する各システムの担当者宛に配布して（ステップＳＡ１５）、図７に示す一連の処理を終える。
【００９９】
このプロセス（１）において、例えば、プロセス管理者ＰＭが主体となって、自車両Ｍに搭載されるシステムとシステム同士の関係を整理して、そのインタフェースを「機構力」、「動作要求」、「情報」の三種類に区分する。また、プロセス管理者ＰＭが主体となって、アイテムの境界の条件（「機構力」等）を明確化して、設計支援システム５００を利用して標準アーキテクチャを作成し、その標準アーキテクチャを登録する。基礎アーキテクチャ作成部５１１は、その標準アーキテクチャを標準アーキテクチャＤＢ５２１に追加して管理する。以降の各プロセスは、この標準アーキテクチャに基づいて行われる。
【０１００】
なお、基礎アーキテクチャは、新たな車両(自車両Ｍ等)の開発が開始される場合などに作成される。その場合，プロセス管理者ＰＭは，開発対象の車両に搭載すべきシステムを決定し、設計支援システム５００を用いて、標準アーキテクチャから開発対象の車両に必要なシステムを抽出する。設計支援システム５００の基礎アーキテクチャ作成部５１１は、必要なシステムの集合体である基礎アーキテクチャを生成し、その基礎アーキテクチャを、基礎アーキテクチャＤＢ５２２に追加して管理する。設計支援システム５００の報知部５５０は、基礎アーキテクチャが作成されたことを、各システムの担当者に報知（配布又は配信等）する。
【０１０１】
［プロセス（２）］
上記のプロセス（２）における初期アーキテクチャを作成する処理（ステップＳＡ２０）について説明する。
図８は、実施形態の初期アーキテクチャを説明するための図である。なお、図８に示された初期アーキテクチャでは、前段の基礎アーキテクチャを生成する段階で択一的に選択された部分であるＨＳ２１０が残されており、ＥＮＧＳ２６０と変速機２６５が削除されている。
【０１０２】
図９は、実施形態に係る初期アーキテクチャを作成する処理の手順を示すフローチャートである。
【０１０３】
まず、初期アーキテクチャ作成部５１２は、作成された基礎アーキテクチャにおいて、システム間のインタフェースの不整合性を検証する（ステップＳＡ２１）。
【０１０４】
初期アーキテクチャ作成部５１２は、作成された基礎アーキテクチャにおいて、システム間のインタフェースに不整合があるか否かを判定する（ステップＳＡ２２）。ステップＳＡ２２の判定の結果により、基礎アーキテクチャにおいて、システム間のインタフェースに不整合が無い場合には、初期アーキテクチャ作成部５１２は、処理をステップＳＡ２５に進める。
【０１０５】
ステップＳＡ２２の判定の結果により、基礎アーキテクチャにおいて、システム間のインタフェースに不整合がある場合には、初期アーキテクチャ作成部５１２は、基礎アーキテクチャの変更が必要か否かを判定する（ステップＳＡ２３）。例えば、初期アーキテクチャ作成部５１２は、基礎アーキテクチャの変更の必要性がないという判定を、システム担当者からの申告などに基づいて実施してもよい。なお、システム間のインタフェースが不足している場合などは、基礎アーキテクチャの変更が必要である場合の一例である。
【０１０６】
ステップＳＡ２３の判定の結果により、基礎アーキテクチャの変更が必要ではない場合、初期アーキテクチャ作成部５１２は、その基礎アーキテクチャに基づいてシステム間のインタフェースを整合させるための処理をする（ステップＳＡ２４）。例えば、システム間のインタフェースに設定された使用条件を調整することで整合する場合には、初期アーキテクチャ作成部５１２は、その使用条件を調整して、その不整合な状況にあるインタフェースを整合させる。インタフェースの上流側のシステムがそのインタフェースを使用することを予定していないのに対し、下流側のシステムが使用することを予定していた場合などは、使用条件が不整合な場合の一例である。なお、インタフェースに係る両システムが、当該インタフェースを使用しないことを確認できれば、システム間のインタフェースが過剰であると判定できる。ただし、この場合は、単に当該インタフェースを使用しないことを設計支援システム５００に登録することで整合をとることができるので、基礎アーキテクチャの変更が必要ではない場合の一例として扱うことができる。
【０１０７】
ステップＳＡ２４の処理を終えて基礎アーキテクチャにおける不整合な状況が解消した後、又は、ステップＳＡ２２の判定の結果が基礎アーキテクチャにおける不整合な状況がないとされた後に、初期アーキテクチャ作成部５１２は、基礎アーキテクチャに基づいた初期アーキテクチャを、初期アーキテクチャＤＢ５２３に登録し（ステップＳＡ２５）、図９に示す一連の処理を終える。
【０１０８】
一方、ステップＳＡ２３の判定の結果により、基礎アーキテクチャの変更が必要である場合、初期アーキテクチャ作成部５１２は、基礎アーキテクチャの変更を要求するための処理をして（ステップＳＡ２６）、図９に示す一連の処理を終える。
【０１０９】
例えば、開発車両の自車両Ｍにおいて使用するインタフェースを特定する際等に、システムの担当者は，設計支援システム５００から報知された基礎アーキテクチャ(図６)に基づいて、当該インタフェースに対応する関連システムの担当者と、そのインタフェースを使用するか否かを調整して、初期アーキテクチャ（図８）に関する基礎データを整理する。なお、インタフェースに対応する関連システムとは、インタフェースを挟む上流側システムと下流側システムのことである。
【０１１０】
例えば、ＩＦ１、ＩＦ２、ＩＦ８、ＩＦ１０は、上流側システムと下流側システムの双方で使用することが合意されたインタフェースであり、ＩＦ３、ＩＦ９、ＩＦ１１は、双方で使用しないことが合意されたインタフェースであり、ＩＦ６は、双方で調整のうえ、条件付きで使用することが合意されたインタフェースであり、ＩＦ１３は、双方で使用しないことを確認して、合意されたインタフェースである。
【０１１１】
なお、条件付きで使用する場合とは、例えば、そのインタフェースを制限して使用する場合の他、そのインタフェースを介して伝える情報に、故障が生じていることを下流側システムに知らせる情報を付加して使用する場合等が含まれる。後者の場合、上流側システムと下流側システムの双方で、故障が生じていることを知らせる情報を使用することを条件として合意することがある。
【０１１２】
上記の図８において、各インタフェースの上流側システムと下流側システムを起点とし、インタフェースに沿って記載された点線の矢印は、上記の合意形成のために上流側システムと下流側システムのそれぞれから提供される使用又は不使用などの情報を示す。例えば、ＩＦ１、ＩＦ２、ＩＦ８、ＩＦ１０のインタフェースに沿うように記された細い点線の矢印ＵＳＥは、上流側システムと下流側システムのそれぞれから「使用」を示す情報が提供されたことを示す。ＩＦ１３のインタフェースに沿うように記された太い点線の矢印ＤＩＳＵは、上流側システムと下流側システムのそれぞれから「不使用」を示す情報が提供されたことを示す。ＩＦ６のインタフェースにおいて、上流側システムから「不使用」を示す情報が提供され、下流側システムから「使用」を示す情報が提供されたことを示す。
【０１１３】
初期アーキテクチャ作成部５１２は、上記のように上流側システムと下流側システムからそれぞれ提供される情報を取得して、それを可視化する。システムの担当者は、それらの情報に基づいて互いに合意して、インタフェースごとに、使用又は不使用、使用の際の条件等を決定する。
【０１１４】
この図８の１つの特徴として、任意の１つのインタフェースの合意状況が情報の流れを示す図中に描かれていることである。
また、他の１つの特徴として、任意の１つのインタフェースにその上流側システムと下流 側システムとから各々の関連を示す点線の矢印が、システム間のインタフェース（実線の矢印）とは別に描かれていることである。なお、実線の矢印の向きは、作動部を作動させるように情報を伝える方向を示す。
これらによって、関係者同士がお互いの関係と結果をより容易に把握することが可能になっている。
【０１１５】
システムの担当者は、その調整の結果の基礎データを設計支援システム５００に登録する。設計支援システム５００の初期アーキテクチャ作成部５１２は、当該システムに関する初期アーキテクチャ（図８）を作成し、それを初期アーキテクチャＤＢ５２３に登録する。
【０１１６】
なお、初期アーキテクチャを作成する際に関連システムの担当者と整合をとった結果、インタフェースや関連システムが足りないことが判明する場合がある。このような場合、システムの担当者は，設計支援システム５００を利用して、関連システムの担当者との整合の結果を，プロセス管理者ＰＭに通知して、初期アーキテクチャの変更を要求する。プロセス管理者ＰＭは，上記の要求を受けると、変更対象のシステムの初期アーキテクチャを更新して、新たな初期アーキテクチャを初期アーキテクチャＤＢ５２３に追加して更新する。なお、プロセス管理者ＰＭは，上記の変更対象のシステムの初期アーキテクチャの更新に合わせて、基礎アーキテクチャＤＢ５２２における基礎アーキテクチャについても同様に更新してもよい。
【０１１７】
［プロセス（３）］
上記のプロセス（３）におけるハザードの影響を分析する処理（ステップＳＡ３０）について説明する。
【０１１８】
図１０は、実施形態のハザードの影響の分析について説明するための図である。図１０に示す構成は、前述の初期アーキテクチャ（図８）に基づくものであり、不使用と判断されたインタフェースの表示を省略している。ここでは、駆動系ハザードを例示して、その影響について分析する事例について説明する。
【０１１９】
図１１は、実施形態に係るハザードの影響を分析する処理の手順を示すフローチャートである。
【０１２０】
まず、影響分析部５１３は、判定対象のシステムが作動部を含むものであるか否かを判定する（ステップＳＡ３１）。ステップＳＡ３１の判定の結果により、判定対象のシステムが作動部を含むものではない場合には、影響分析部５１３は、図１１に示す一連の処理を終える。
【０１２１】
ステップＳＡ３１の判定の結果により、判定対象のシステムが作動部を含むものである場合には、影響分析部５１３は、作動部を作動することに関するハザードについて、そのＡＳＩＬを評価して（ステップＳＡ２２）、その結果をハザード分析情報ＤＢ５２４に格納する。
【０１２２】
次に、影響分析部５１３は、判定対象のシステムが上記の作動部を作動させるための要求を受けるか否かを判定する（ステップＳＡ３３）。ステップＳＡ３３の判定の結果により、判定対象のシステムが上記の作動部を作動させるための要求を受けるものではない場合には、影響分析部５１３は、処理をステップＳＡ３７に進める。
【０１２３】
ステップＳＡ３３の判定の結果により、判定対象のシステムが上記の作動部を作動させるための要求を受けるものである場合には、影響分析部５１３は、その作動部を作動させるための要求について、ＡＳＩＬを割りあてて（ステップＳＡ３４）、その結果をハザード分析情報ＤＢ５２４に追加する。
【０１２４】
次に、影響分析部５１３は、作動部を作動させるための要求にＡＳＩＬが割りあてられたことを、要求を出力するシステムの担当者に対して報知部５５０を介して報知する（ステップＳＡ３５）。
【０１２５】
次に、影響分析部５１３は、要求を出力するシステムの担当者の要求などに応じて、当該要求を出力するシステムの各インタフェースに割り当てられたＡＳＩＬを取得する（ステップＳＡ３６）。
【０１２６】
ステップＳＡ３６の処理により、要求を出力するシステムのインタフェースに割り当てられたＡＳＩＬを取得した後、又は、ステップＳＡ３３において判定対象のシステムが作動部を作動させるための要求を受けるものではないと判定された後に、影響分析部５１３は、コンセプト設計と影響分析を評価して（ステップＳＡ３７）、その結果をハザード分析情報ＤＢ５２４に追加して、図１１に示す一連の処理を終える。
【０１２７】
例えば、図１０に示す機構力（駆動力Ｆ１と制動力Ｆ２）に関するハザードの分析について、その一例を説明する。ＨＳ２１０は、機構力として駆動力Ｆ１を出力するシステムである。自システムが機構力を出力するものである場合、そのシステムの担当者は、ハザード分析およびリスクアセスメントを実施して機構力が持つハザードのＡＳＩＬを評価する。この例では、そのハザードのＡＳＩＬは「ASIL B」と評価される。設計支援システム５００は、その評価の結果を受け付けて、駆動力Ｆ１に対応するＨＳ２１０のＡＳＩＬを、上記と同じ「ASIL B」に決定する。
【０１２８】
ＨＳ２１０は、自システムが、機構力Ｆ１に作用するための動作要求（要求駆動力）を、ＩＦ１のインタフェースを介して上流側のＣＯＮＴ１００から受け付けるものであり、その機構力Ｆ１がＡＳＩＬにより管理される。上記のような場合、設計支援システム５００は、その動作要求に対して、ＨＳ２１０のＡＳＩＬと同じ「ASIL B」を割り当てて、その後、その動作要求の要求元であるＣＯＮＴ１００の担当者に通知する。
その後、動作要求の要求元であるＣＯＮＴ１００の担当者は、設計支援システム５００によって通知された「動作要求に対するＡＳＩＬ」を確認する。図１０に示す場合、ＩＦ１のインタフェースを介した「動作要求に対するＡＳＩＬ」は、「ASIL B」である。
【０１２９】
なお、同様にＶＳＡＳ２２０は、機構力として制動力Ｆ２を出力するシステムである。設計支援システム５００は、その評価の結果を受け付けて、制動力Ｆ２に対応するＶＳＡＳ２２０のＡＳＩＬを、「ASIL D」に決定する。なお、ＶＳＡＳ２２０は、ＩＦ２のインタフェースを介して上流側のＣＯＮＴ１００から制御状態に関する情報を受けるものであるが、制動力Ｆ２に作用するための動作要求（要求制動力など）を受けるものではない。このＩＦ２のインタフェースを介して、ＶＳＡＳ２２０の上流側のＣＯＮＴ１００には、制動系ハザードは影響しないと判定できる。
【０１３０】
続いて、上記のコンセプト設計と影響分析の評価のより具体的な事例について説明する。図１２は、実施形態に係るコンセプト設計と影響分析を評価する処理の手順を示すフローチャートである。
【０１３１】
まず、影響分析部５１３は、各システムの内部の影響を分析する（又は、その結果を取得する）（ステップＳＡ３７１）。例えば、各システムの内部の影響を分析とは、その内部をさらに機能分割して構成した際に、当該システムの上流側又は下流側からの影響の伝搬を、上記のシステム間の関係の場合の処理と同様の方法で実施する処理としてもよい。その際に、必要に応じて、システムの内部に安全機構要素を配置するようにしてもよい。
【０１３２】
次に、影響分析部５１３は、各システムの内部の影響分析の結果に基づいてインタフェースにＡＳＩＬを割り当てる（ステップＳＡ３７２）。
【０１３３】
次に、影響分析部５１３は、上記のインタフェースに対応する他のシステムの担当者に、ＡＳＩＬが割り当てられたことを報知する（ステップＳＡ３７３）。
【０１３４】
次に、影響分析部５１３は、上記のインタフェースに既に割り当てられていたＡＳＩＬに対し、同インタフェースに後から新たに割り当てられたＡＳＩＬが、より安全度水準が高いものであるか否かを判定する（ステップＳＡ３７４）。ステップＳＡ３７４において、新たに割り当てられたＡＳＩＬが、割り当てられていたＡＳＩＬと同等又はそれ以下の安全度水準である場合、この図１２に示す一連の処理を終える。
【０１３５】
ステップＳＡ３７４において、新たに割り当てられたＡＳＩＬが、より安全度水準が高いものである場合、影響分析部５１３は、コンセプト設計と影響分析を再度実施するための処理を実施して（ステップＳＡ３７５）この図１２に示す一連の処理を終える。
【０１３６】
ここで、実施形態のシステム間の影響分析について説明する。図１３は、実施形態のシステム間の影響分析について説明するための図である。例えば、ＣＯＮＴ１００などの各システムの担当者は、安全機構要素の配置を想定した自システム内のコンセプト設計を行い、当該システム内の影響分析を実施する。
【０１３７】
上記の安全機構要素の配置を想定したシステムとは、システムの基本機能を司る要素機能（Functional Element）の他に、上流側のシステム又は自システム内で生じた意に反する事象の影響を軽減させる機能要素のことである。実施形態の例では、例えば、ＨＭＩ制御部１１０を要素機能とした場合に、走行制御部１２０と自動運転制御部１３０とが連携して、安全機構要素として作用する。
【０１３８】
例えば、ＣＯＮＴ１００において、ＨＭＩ制御部１１０は、ＥＰＳＳ２５０からステアリング情報と、各種スイッチ情報と、各種センサ情報とを受け、走行制御部１２０に対して、それらの情報から決定した「情報」を供給する。一方、自動運転制御部１３０は、ＶＳＡ状態と、各種スイッチ情報と、各種センサ情報とに基づいて決定した「駆動要求」を走行制御部１２０に対して供給し、制御状態に関する「情報」をＶＳＡＳ２２０に対して供給する。ここで、自動運転制御部１３０は、ＶＳＡ状態と、各種スイッチ情報と、各種センサ情報とに基づいた解析により不自然な制御状態を検出した場合に、走行制御部１２０に対する「駆動要求」を調整する。
【０１３９】
上記のように構成する場合、影響分析部５１３は、ＩＦ１のインタフェースの「駆動要求」の経路に沿って順にさかのぼり、走行制御部１２０と自動運転制御部１３０とに「ASIL B」を割り当てる。影響分析部５１３は、走行制御部１２０に対して駆動要求を供給しないＨＭＩ制御部１１０については、「QM」を割り付ける。
【０１４０】
設計支援システム５００は、ＣＯＮＴ１００内の各部に割り付けられた「ASIL」又は「QM」に基づいて、ＣＯＮＴ１００の各インタフェースに上記のように決定したＡＳＩＬを割り当てて、上記の各インタフェースに対応する関連システムの担当者に通知する。
【０１４１】
システムの担当者は、設計支援システム５００からの通知を受け、自システムのインタフェースに割り当てられたＡＳＩＬ、並びに、コンセプト設計で想定した安全機構要素の有効性を確認する。
【０１４２】
図１４は、実施形態のシステム間のインタフェースに割り当てられたＡＳＩＬを確認するための方法について説明するための図である。
【０１４３】
例えば、設計支援システム５００は、ＩＦ１０のインタフェースについて、その上流側に位置付けられるＶＳＡＳ２２０が示すＶＳＡ状態の安全度水準（「QM」）と、その下流側に位置付けられる自動運転制御部１３０に割り付けられた安全度水準「ASIL B」とを対比して、下流側の安全度水準「ASIL B」の方が上流側の安全度水準（「QM」）より高いことを確認する。
【０１４４】
また、設計支援システム５００は、ＩＦ２のインタフェースについて、その下流側に位置付けられるＶＳＡＳ２２０が示す安全度水準（「ASIL A」）と、その上流側に位置付けられる自動運転制御部１３０に割り付けられた安全度水準「ASIL B」とを対比して、下流側の安全度水準「ASIL A」の方が上流側の安全度水準（「ASIL B」）より高いことを確認する。
【０１４５】
設計支援システム５００は、ＩＦ８のインタフェースについては、その上流側に位置付けられるＥＰＳＳ２５０が示す安全度水準が「QM」であり、その下流側に位置付けられるＨＭＩ制御部１１０に割り付けられた安全度水準も、同じ「QM」であることから、安全度水準の割り付けに問題が無いことを確認する。
【０１４６】
この図１４の１つの特徴は、任意のインタフェースに関する安全度水準の関係を、システム間のインタフェース（実線の矢印）とは別に、例えば点線の矢印などで、図示していることである。
これによって、ユーザーは任意のインタフェースに関する安全水準の関係をより容易に把握することができる。
【０１４７】
なお、前述の図１３に示す範囲には該当しないが、想定したＡＳＩＬよりも高いＡＳＩＬが割り当てられた等の場合は，コンセプト設計と影響分析とを見直すことを、各システムの担当者に要求する。
【０１４８】
［プロセス（４）］
上記のプロセス（４）におけるシステム間の機能安全要求の整合の検証を支援する処理（ステップＳＡ４０）について説明する。図１５は、実施形態に係るシステム間の機能安全要求の整合の検証を支援する処理の手順を示すフローチャートである。図１６と図１７は、実施形態に係るシステム間の機能安全要求の整合の検証を支援する処理について説明するための図である。
【０１４９】
まず、対象のインタフェースに、ＡＳＩＬの割り当てを要求したシステムが、検証の基準にするシステム（以下、自システムという。）であるか、或いは、他の関連システムであるかを判定する（ステップＳＡ４１）。
【０１５０】
ステップＳＡ４１において、自システムであると判定した場合、機能安全要求整合判定部５１４は、自システムに対する関連システム側と整合をとり、その整合の結果を合意するための処理をする（ステップＳＡ４２）。例えば、図１６に示すように、ＣＯＮＴ１００の担当者が、ＩＦ１、ＩＦ２、ＩＦ１０の各インタフェースのＡＳＩＬの割り当てを要求した場合、ＣＯＮＴ１００の担当者は、ＣＯＮＴ１００に対する関連システムの各部の担当者と整合をとる。例えば、ＣＯＮＴ１００に対する関連システムは、ＨＳ２１０、その下流側に位置づけられるＶＳＡＳ２２０、その上流側に位置づけられるＶＳＡＳ２２０などである。設計支援システム５００は、その整合の結果を受け付けて、例えば、整合の結果、整合が完了したことなどを、機能安全要求情報ＤＢ５２５に書き込み、また、その結果を端末装置６００から参照可能にしてもよい。この段階で、設計支援システム５００の機能安全要求整合判定部５１４は、合意が形成されたと判定する。
【０１５１】
ステップＳＡ４１において、関連システムであると判定した場合、自システムに対する関連システム側と整合をとり、その整合の結果を合意するための処理をする（ステップＳＡ４３）。例えば、図１７に示すように、ＣＯＮＴ１００に関連するシステムの担当者が、ＩＦ１、ＩＦ２の各インタフェースのＡＳＩＬの割り当てを要求した場合、ＣＯＮＴ１００に関連するシステムの担当者は、ＣＯＮＴ１００の担当者等と整合をとる。なお、実勢形態のＣＯＮＴ１００に関連するシステムとは、例えば、ＨＳ２１０、下流側に位置づけられるＶＳＡＳ２２０などの各部である。設計支援システム５００は、その整合の結果を受け付けて、例えば、整合の結果、整合が完了したことなどを、機能安全要求情報ＤＢ５２５に書き込み、また、その結果を端末装置６００から参照可能にしてもよい。この段階で、設計支援システム５００の機能安全要求整合判定部５１４は、合意が形成されたと判定する。
【０１５２】
この図１７の「調整の上、条件付きで使用することに合意」とは、インタフェースを制限して使用することだけでなく、例えば、そのインタフェースの情報として、上流側システムなどが故障していることを知らせる情報を付加することなども含まれることを意味する。
【０１５３】
図１６、図１７の１つの特徴は、任意のインタフェースに関する安全度水準の関係に加え、合意に関する結果を、システム間のインタフェース（実線の矢印）とは別に、例えば点線の矢印などで、図示していることである。
【０１５４】
これによって、ユーザーは任意のインタフェースに関する合意に関する結果をより容易に把握することができる。
【０１５５】
上記のステップＳＡ４２又はステップＳＡ４３の処理を終えて、図１５に示す一連の処理を終える。
【０１５６】
図１８は、実施形態の機能安全要求情報ＤＢ５２５の一例を示す図である。機能安全要求情報ＤＢ５２５には、インタフェースを識別するためのＩＦ＿ＩＤ、そのインタフェース上流側（送信元）と下流側（宛先）を示す情報、配信情報、インタフェースを使用するか否かの情報(適用)、要求されるＡＳＩＬのランクとその割付を要求したシステム、ＡＳＩＬの要求の有無、整合性の判定結果、整合性の合意状況などの情報が含まれる。機能安全要求情報ＤＢ５２５には、インタフェースごとに、上記の情報が格納される。
【０１５７】
［プロセス（５）］
上記のプロセス（５）における標準アーキテクチャの更新要求に対する処理（ステップＳＡ５０）について説明する。このプロセス(５)に関する処理は、前述の図７に示すように必要に応じて実施される。
【０１５８】
例えば、完成されたアーキテクチャにインタフェース等が新たに追加されたなどの場合には、設計支援システム５００は、各システムの担当者から標準アーキテクチャの更新要求を受けることがある。この場合、プロセス管理者ＰＭは、その更新要求の理由とされている「追加が必要とされるインタフェース」等を標準アーキテクチャに追加するか否かを判定し、その判定の結果に基づいて、必要に応じてその構成を標準アーキテクチャに追加して、それを更新することを許可する。なお、更新された標準アーキテクチャは、次回の車両の開発時等に、技術資産として使用可能なものとして扱われる。
【０１５９】
［プロセス（６）］
上記のプロセス（６）における詳細設計段階の機能安全活動の実施を支援するための処理（ステップＳＡ６０）について説明する。例えば、少なくとも上記のプロセス(４)までが完了した後、各システムの担当者は、担当するシステムの詳細設計を進める。
【０１６０】
この段階で、設計支援システム５００は、システムの担当者による、国際規格におけるＰＡＲＴ４（システムレベルの開発）以降の機能安全活動の実施を支援する。上記の通り、プロセス（４）までの機能安全活動で、自システムにおける各インタフェースに関する要求条件が明確なものとなっている。設計支援システム５００は、そのインタフェースの使用／不使用の区別、使用する場合の条件などを、各システムの担当者の要求により適宜表示するようにしてもよい。
【０１６１】
以上に示した各プロセスの処理を通して、車１台分の設計における機能安全活動が実施される。
【０１６２】
図１９と図２０とを参照して、設計支援システムが生成した情報の表示の一例について説明する。図１９と図２０は、実施形態の設計支援システム５００が生成した情報を表示する画面の一例について説明するための図である。
【０１６３】
図１９に示す例は、比較的広い面積で表示可能な表示装置を有する端末装置６００などに適した表示の一例である。上記の表示装置は、例えば、ＬＣＤや有機ＥＬなどを含むものである。このような端末装置６００としては、例えば、公称寸法で１０型（インチ）から１５型（インチ）程度の大きさの表示装置を有するパーソナルコンピュータ、又は、タブレット装置などが好適である。またＣＡＤ（computer-aided design）用画面装置など、それ以上の大型画面表示装置であっても良い。
【０１６４】
符号６１０は、各種情報を纏めて表示する場合の画面の範囲を示す。この画面には、設計システムの名称（Ｚ０）、対象製品名（車種名）などの設計対象全体を総称した情報（Ｚ１）、全体の検証状況についての情報（Ｚ２）、設計対象全体の内の一部である検証対象についての情報（Ｚ３）、プロセスの段階を示す情報（Ｚ４）、対象製品又は設計業務に適用すべき規格や条件に関する情報などの情報（参考情報）（Ｚ５）、上流側システムの担当者と検証の結果（Ｚ６、Ｚ７）、下流側システムの担当者と検証の結果（Ｚ８、Ｚ９）、検証対象の位置を示す模式図（Ｚ１０）などの各種情報が表示された領域と、それらの表示を切換えたり、情報を入力したりするための各種操作アイコンの図形が表示された領域（Ｚ２０）が含まれている。なお、上記の「検証の結果」は、対象製品又は設計業務に適用すべき規格や条件に基づいた検証の結果であり、その表示に、上記の「規格や条件」に対する対応案、設定案、回答等のうちの何れかが含まれていてもよい。それらは検証が行われる段階に応じたものであって良い。
なお、前述の各種操作アイコンは適宜の形態で良く、上下左右にスライド可能なコマンドバーであっても良い。また音声入力も可である。
また、参照できる模式図（Ｚ１０）は、制御信号等を示す図でも良いし、図８、図１０、図１３、図１４、図１６、図１７或いは図２１に示されるような、その時々の検証に適した情報が掲示されている図であっても良い。
【０１６５】
このような情報を表示することにより、上流側システムと下流側システムの双方の検証が終わっているか否かを知ることができる。また、上記の双方の検証が終わった場合に、その結果が一致しているか否かを知ることができる。そして、その結果が一致したことを可視化してもよい。例えば、文字や記号による標記、 色や明暗による識別でも良い。これによって、機能安全の検証の結果を容易に共有することができ、検証作業の効率を向上させることができる。
【０１６６】
図２０に示す例は、比較的狭い面積で表示可能な表示装置を有する端末装置６００などに適した表示の一例である。上記の表示装置は、例えば、ＬＣＤや有機ＥＬなどを含むものである。このような端末装置６００としては、例えば、公称寸法で４型（インチ）から７型（インチ）程度の概ね１０型に満たない大きさの表示装置を有するスマートフォン、又は、比較的小型のタブレット装置などが好適である。
【０１６７】
符号６１０Ａと６１０Ｂは、各種情報を２画面に分割して表示する場合の画面の範囲を示す。ここでは、この場合の画面は、模式図以外の各所情報を表示する画面６１０Ａ（図２０（ａ））と、模式図を表示する画面６１０Ｂ（図２０（ｂ））とに分けた場合を例示するものである。
【０１６８】
例えば、設計支援システム５００の記憶部５２０は、各システム（機能部）に関する検証のための情報を、各種ＤＢ内に保持している。上記の検証のための情報には、安全度水準を示す値（「ASIL A」、「QM」など）、自システムを基準に据えた影響が及ぶ範囲、データの登録日などの日付、関連する規定の版数（発行版）などが含まれる。
【０１６９】
例えば、情報取得部５４０は、プロセスの管理者ＰＭ、各システムの担当者等のユーザーの要求を、端末装置６００を介して取得する。
【０１７０】
プロセスの管理者ＰＭ、各システムの担当者等のユーザーが情報を確認する場合には、設計支援システム５００は、下記のように機能する。
【０１７１】
報知部５５０は、端末装置６００からの要求に応じて、プロセスの管理者ＰＭ、各システムの担当者が確認すべき情報、つまり検証のための情報を纏めた上記の画面を生成して、当該端末装置６００に表示させる。上記の画面の例には、検証の段階を示す情報、自システム（検証対象）に対して上流側のシステムと下流側のシステムとの検証の結果などの、検証のための情報がそれぞれ含まれている。なお、端末装置６００は、表示手段の一例である。
【０１７２】
プロセスの管理者ＰＭ、各システムの担当者等のユーザーが情報を登録する場合には、設計支援システム５００は、下記のように機能する。
【０１７３】
情報取得部５４０は、端末装置６００から、ＣＯＮＴ１００からＨＳ２２０へ供給される信号に関する検証結果を取得する。その検証結果には、ＣＯＮＴ１００からＨＳ２２０へ供給される信号に関するＣＯＮＴ１００側の第１の検証結果の入力の有無と、上記信号に関するＨＳ２２０側の第２の検証結果の入力の有無とが、上記の画面の例に含まれている。報知部５５０は、上記の画面を端末装置６００に送り、ユーザーに報知する。なお、上記の表示の例では、第１の検証結果の入力の有無と、第２の検証結果の入力の有無の双方を、１つの画面に表示するように画面を構成しているが、２つの画面に分けて表示することを制限するものではなく、報知部５５０は、上記検証結果の入力の有無の少なくとも一方を報知可能とするようにしてもよい。
【０１７４】
上記の通り、端末装置６００は、設計支援システム５００が生成した情報を表示することにより、その情報を各システムの担当者、プロセス管理者ＰＭなどに供給することができる。
【０１７５】
なお、本実施形態に示した手法を、完成車全てに適用することに代えて、主要な部分に適用することを制限するものではない。この場合、完成車全てに適用することに比べて、システム相互の関係の網羅性が低減するが、そのような範囲については他の手法を適用して実現するようにしてもよい。
【０１７６】
上記の実施形態によれば、制御システムは、車両の運転者の操作または車両の司令部の指示に応じて前記車両の少なくとも一部を作動させるものである。自車両Ｍは、複数の作動部と、複数の作動部を制御するための制御システムとを有する。複数の作動部のうちの任意の作動部は、運転者の操作または司令部の指示に基づいて作動するように設定されている。
【０１７７】
その制御システムは、少なくとも任意の作動部に関する複数の機能部であって、作動部の作動に関し直列の関係にある複数の機能部を有している。なお、作動部の作動に関し直列の関係は、上流側と下流側との関係にある場合を含むものであってもよい。その複数の機能部は、その複数の機能部の間で作動部の作動のための信号の送り側となる第１機能部と、その信号の受け側となる第２機能部と、を含むものである。
【０１７８】
実施形態の設計支援システムは、上記の車両の運転者の操作または車両の司令部の指示に応じて前記車両の少なくとも一部を作動させる制御システムの設計を下記のように支援する。設計支援システムは、第１機能部から第２機能部へ供給される信号に関する検証結果を取得する取得部と、第１機能部から第２機能部へ供給される信号に関する第１機能部側の第１の検証結果の入力の有無と、上記信号に関する第２機能部側の第２の検証結果の入力の有無と、の少なくとも一方を報知可能とする報知部と、を備えることにより、複数の要素に機能分割された制御システムの設計の検証を、効率よく実施することができる。
【０１７９】
なお、設計支援システムは、機能部に関する検証のための条件を記憶する記憶部を備え、報知部は、検証のための条件を表示手段に表示させてもよい。なお、報知部は、検証のための条件と、その条件に対する対応案、設定案、回答などを、前述の図表示手段に表示させてもよい。
【０１８０】
なお、報知部は、第１の検証結果と第２の検証結果とに基づいた第１機能部と第２機能部に関する設計段階（設計プロセス）を報知してもよい。
【０１８１】
さらに、上記の実施形態によれば、設計支援システムは、少なくとも第１機能部に関する情報と、第２機能部に関する情報と、第１機能部から第２機能部へ供給される信号に関する情報と、少なくとも第１機能部または第２機能部の設計または検証に関わる人に関する情報と、を表示手段に表示させる報知部を備えることにより、複数の要素に機能分割された制御システムの設計の検証を、効率よく実施することができる。
【０１８２】
なお、別の観点によれば、実施形態に係る設計支援システムは、ユーザーの操作に応じて駆動部を駆動させる制御システムを設計対象とし、当該制御システムに関する機能安全の設計を支援する。設計支援システムに係る当該制御システムは、複数の機能部を含み、前記複数の機能部には前記駆動部を駆動させるための処理が当該処理の流れに従って機能分割されて割り付けられており、前記複数の機能部のそれぞれが、それぞれに割り付けられた処理を実施して前記駆動部を駆動させるものである。設計支援システムは、複数の機能部のうち、その処理に係る指令を送出する第１機能部と、第１機能部から送出された指令を受ける第２機能部とについて、第１機能部と第２機能部との間の指令に係る信号が、機能分割に従い決定され、第２機能部の機能と当該信号との関係が機能安全の要求度を満足することを検証する検証部を備えることにより、複数の要素に機能分割された制御システムの設計の検証を、効率よく実施することができる。
【０１８３】
（第２の実施形態）
第２の実施形態について説明する。第１の実施形態では、メカニズムとしての作動部は、機械的に可動するもの（駆動輪Ｗ１）に適用した事例について例示して説明した。これに代えて、本実施形態におけるメカニズムとしての作動部は、電気的に機能するものである。これに適用した事例について説明する。
【０１８４】
ここで例示する作動部は、灯具２４０の前照灯、ポジション灯などである。
図２１は、実施形態の実施形態のハザードの影響の分析について説明するための図である。影響分析部５１３は、前述のプロセス（３）に基づいて、灯具２４０を点灯中に生じ得るハザードについて判定する。例えば、灯具２４０が意に反して突然消灯して自車両Ｍの周囲が暗闇になる場合を想定し、そのハザードに対するＡＳＩＬを「ASIL-α」に決定する。「ASIL-α」は、ＡＳＩＬとして定められた何れかの水準を示す。
【０１８５】
次に、影響分析部５１３は、灯具２４０が意に反して突然消灯する要因を抽出する。
例えば上記の要因の抽出の結果から、その影響を分析すると下記のような事象が想定される。
【０１８６】
・オートライト機能を活性化させるためのオートライトスイッチが故障して、オートライト機能を停止させる状態（非活性化状態）を指定する状態を保持し続けるOFF故障になると灯具２４０を消灯することが有る。
【０１８７】
・明るさセンサが明るいと誤認識すると灯具２４０を消灯することが有る。
【０１８８】
・灯具２４０に電力を供給する電源（例えば、12V系）が、意に反して突然遮断された状態になると灯具２４０を消灯する。
【０１８９】
上記の他、例えば、灯具２４０の点灯を要求するシステムに、遠隔操作でエンジンを始動させるためのリモートエンジンスタートシステム（不図示）等がある。リモートエンジンスタートシステムは、灯具２４０の点灯を単に要求するものであれば、灯具２４０を消灯させることはない。その場合、仮にリモートエンジンスタートシステムが故障しても、その故障が、灯具２４０が意に反して突然消灯する要因にはならない。
【０１９０】
次に、影響分析部５１３は、上記に挙げた事象に関係するインタフェースとシステムに「ASIL-α」を通知する。その通知の結果から、例えば、ＢＭＳ２７０により供給状況が制御される電力（電源）が、灯具２４０における前照灯等の点灯状態に影響すること、その灯具２４０が、上記の電力を供給している時に「ASIL-α」の危険度を持つこと、などが明らかになる。
【０１９１】
上記のプロセスにより、ＢＭＳ２７０が、灯具２４０に対して「ASIL-α」の危険度を有しているものであることが明示され、ＢＭＳ２７０の担当者は、それを認識することができる。
【０１９２】
この図２１の１つの特徴は、規格などによる任意のインタフェースに関する安全度水準についての情報を、システム間のインタフェース（実線の矢印）とは別に、例えば点線の矢印などで、図示していることである。
【０１９３】
これによって、ユーザーは任意のインタフェースに関する安全度水準についての情報をより容易に把握することができる。
【０１９４】
本実施形態によれば、第１の実施形態と同様の効果を奏することの他、電気的に作動する作動部に係る事象についても、適用可能であることが分かる。
【０１９５】
（各実施形態に共通の効果）
続いて、実施形態に共通の効果について説明する。
少なくとも実施形態の機能安全システムは、車両の運転者の操作または車両の司令部の指示に応じて前記車両の少なくとも一部を作動させるための制御システムの設計支援システムである。前記車両は、複数の作動部と、前記複数の作動部を制御するための制御システムとを有しており、前記複数の作動部のうちの任意の作動部は、前記運転者の操作または前記司令部の指示に基づいて作動するように設定されており、前記制御システムは、少なくとも前記任意の作動部に関する複数の機能部であって、前記作動部の作動に関し直列の関係にある複数の機能部を有しており、前記複数の機能部は、前記複数の機能部の間で前記作動部の作動のための信号の送り側となる第１機能部と、前記信号の受け側となる第２機能部と、を含むものであって、当該設計支援システムは、前記第１機能部から前記第２機能部へ供給される信号に関する検証結果を取得する取得部と、前記第１機能部から前記第２機能部へ供給される信号に関する前記第１機能部側の第１の検証結果の入力の有無と、上記信号に関する前記第２機能部側の第２の検証結果の入力の有無と、の少なくとも一方を報知可能とする報知部と、を備えるものである。これにより、上記の効果の他、さらに、下記の効果を奏するものである。
【０１９６】
・開発段階の不要な工数の削減について
本実施形態に関連する国際規格では、ウォータフォール型のＶ字モデルの開発プロセスの適用を定めている。国際規格では、ＰＡＲＴ３コンセプト設計を実施した後に、ＰＡＲＴ４システムレベルの開発を着手するものとされている。
このＰＡＲＴ３コンセプト設計の段階で、本実施形態を適用することにより、ＰＡＲＴ４システムレベルの開発を開始するまでに機能安全の機能の割り付けが明確になる。これにより、ＰＡＲＴ４システムレベルの開発の段階に入ってから、機能の割り付けが不完全であることに起因する手戻りが生じることを抑制することができる。
【０１９７】
・インタフェースの種別を明確化したことによる解析容易性の向上について
実施形態の機能安全のプロセスでは、インタフェースを、そのガイドとして利用する。前述の図４等に示すように、そのインタフェースは、そのインタフェースを利用して伝達するもの（情報等）の種別により、「機構力」、「動作要求」、「情報」の三種類に区分される。物理的な影響を及ぼす情報を伝達するインタフェースは、「機構力」に分類され、他のシステムの機構力を操作するインタフェースは、「動作要求」に分類され、ハザードに直接影響を与えるかどうか不明なインタフェースは、「情報」に分類される。このように、種別を制限することにより、インタフェースの特徴が明確化されている。
【０１９８】
・ハザードの影響伝達の仕組みの明確化による解析容易性の向上について
ここで、図２２を参照して、実施形態のハザードの影響伝達の仕組みについて改めて整理する。図２２は、ハザードの影響伝達の仕組みについて説明するための図である。
【０１９９】
図２２（ａ）に示す仮定では、例えば，システムＥの内部故障等によりシステムＥが機構(メカニズム)を誤って制御して、異常な機構力を発生させることで、想定外の動きに繋がることがある。このような機構力は、ハザードになることがある。
【０２００】
図２２（ｂ）に示す仮定では、例えば、機構を持たないシステムＦであっても，機構を有するシステムＧに対して動作要求（要求駆動力）を出力した場合、システムＧの機構に影響を与えることがある。このような機構力は、ハザードになることがある。
【０２０１】
また、図２２（ｃ）に示すように、上記のハザードの影響は、ハザードの発生要因となる機構を持つシステムＪから、システムＩやシステムＨを通じてスイッチ（ＳＷ）やセンサなど車両レベルの入力端まで達すると仮定する。
【０２０２】
ここで、図２３を参照して、ハザードの発生を軽減する安全機構要素について説明する。図２３は、ハザードの発生を軽減するための仕組みについて説明するための図である。図２３に示すように、システムＬには、安全機構要素が実装されている。この入力端から、当該ハザードまでの間に、上記の安全機構要素が設けられていることにより、機構部（作動部）に直接的な影響が作用しなくなることで、ハザードが発生する可能性が軽減する。
【０２０３】
一般に上記のような安全機構要素の有効性により、発生し得るリスクの発生確率が変化する。本実施形態によれば、図２２(ｃ)に示す手法を利用して、安全機構要素を配置した位置を容易に決定することができ、また、決定された位置に配置した安全機構要素が有効であることを容易に検証することができる。さらに、本実施形態によれば、安全機構要素の位置、またその安全機構要素があることによって期待できる安全度水準を的確に決定することができる。
【０２０４】
比較例の場合、安全機構要素の位置を的確に決定できないことにより、安全対策が必要とされないシステムに、その安全対策のための機能を過剰に設けてしまう虞がある。
これに対し、本実施形態によれば、安全機構要素の配置などを的確に決定することができ、上記のような事象が生じる虞が無い。
このように、本実施形態に示すように、ハザードの影響伝達の仕組みを明確にしたことで、解析容易性が向上する。
【０２０５】
図２４を参照して、実施形態に係る機能安全に関する検証の範囲について説明する。図２４は、実施形態のアイテムの範囲を示す図である。この図２４に示す「アイテム」の範囲は、自車両Ｍの一部にその範囲が規定されたものである。
【０２０６】
比較例としての一般的な機能安全の検証対象の範囲は、「アイテム」として規定され、その範囲が、電気・電子的に作用して制御するもの（システム）に特定されていることがある。
【０２０７】
これに対して、本実施形態では、自車両Ｍの一部の範囲を「アイテム」として扱うものとしている。上記の実施形態の手法のとおり、機械的作動部や電気的作動部などの各作動部（メカニズム）をシステムの一部として扱うようにしてもよい。そのシステムは、機構力や動作要求を出力して直接的にハザードを引き起こし，情報を介して間接的にハザードを引き起こすものと規定することができる。このため、隣接するシステム間で適切な機能安全要求を割り付けられれば、ハザード要因となる経路全てで安全方策を実施することができる。そこで、同様の手法で解析範囲を拡張して、各作動部を含むシステムも併せて解析するようにした。
【０２０８】
例えば、外部から入力されるインタフェースを有する場合には，インタフェースを通じて連結された他のシステムと機構をアイテム範囲に取り込む。また、外部に出力するためのインタフェースを有する場合には，インタフェースを通じて連結されたシステムと作動部（機構部）、物理的作用（機構力）、関連ハザードをアイテム範囲に取り込む。これにより、本実施形態の「アイテム」の範囲を、電気・電子的に作用して制御するシステムだけの範囲から、各作動部を含む範囲に拡張することができる。また、その作動部が作動させることにより所望の物理的作用を期待する構成における、物理的作用とそれに関連するハザードについても、「ASIL」や「QM」などの所定の安全度水準を割り付けるという同様の解析手法を適用することで、ハザードからその要因までの解析を、共通の解析手法を利用して実施することができる。
【０２０９】
上記の通り本実施形態の機能安全のプロセスは、システム間のインタフェースの規定方法と、ハザードの影響伝達の仕組みとを含み、それらを組み合わせることにより、機能安全設計を支援することができる。
【０２１０】
なお、この図２４に示すように、上記の「アイテム」の範囲を、自車両Ｍの一部に限り適用することも可能であり、適用外の範囲については他の手法を組み合わせてもよい。例えば、他の手法とは、実施形態の設計支援システムを利用しないで実施する機能安全プロセスであってもよく、実施形態の設計支援システムの条件や規格が互いに異なる他の設計支援システムによる機能安全プロセスであってもよい。
【０２１１】
なお、国際規格により安全度水準（ＡＳＩＬ）として規定される内容には、当該システムを検証するための方法や、安全機構要素等に求める安全度水準の検証に必要とされる「条件」などが含まれる。例えば、要求されたＡＳＩＬから、当該システムの開発の難易度を推定することができる。設計支援システム５００は、関連システムの担当者に対して機能安全要求を通知する際には、機能安全要求とＡＳＩＬとを組にして通知するようにしてもよい。
【０２１２】
例えば、あるシステムに、これまでそのシステムに設定されていた安全度水準よりも高いものが要求され、ハードウェアの故障率を低減させるだけでは、要求される安全度水準を確保できないことが有る。これに代わる対策として、当該システムなどへの安全機構要素の追加がある。ただし、その安全機構要素の開発に関する難易度などにより、その開発に必要とされる要員を確保しにくい場合には、当該組織の担当者を増員することなどの対応が必要になる。その際、当該組織以外の者を受け入れたり、当該組織と直接利害関係が無い者までを受け入れたりすることがある。このような対応が必要とされる場合に、設計支援システム５００から、単に機能安全要求が通知されるだけではなく、その機能安全要求にＡＳＩＬが組合わされて通知されることにより、その開発に必要とされるスキル、人員構成、故障検出手法、フェールセーフアクションのやり方などの検討を速やかに開始することができ、システムの詳細な開発を開始するまでに、担当者として適切な人材を確保することができる。
【０２１３】
なお、当該システムに関連する関連システムの担当者から、上記の「条件」に対する対応、設定、又は回答などが、設計支援システム５００に登録され、関係者間でその情報が共有される。
【０２１４】
なお、実施形態による設計支援システム５００又は端末装置６００は、上記の処理を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、当該記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、上述した種々の処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
【０２１５】
さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Dynamic Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【０２１６】
以上、本発明を実施するための形態について実施形態を用いて説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。例えば、本実施形態に示した変形例等を、他の実施形態に適用することができる。また、実施形態では、自動車を設計の対象とする一例について説明したが、これに制限されず、他の態様の移動体を設計の対象にしてもよい。
或いは、家庭用のお掃除ロボットのように、自律して移動し作業を行うサービスロボットを対象にしても良い。
さらには、固定的に設置される作業ロボットでも、上半部が一定範囲内の動作 （伸縮（往復動）、傾動、搖動、回動や回転の姿勢の変化など ）を伴う家庭用、商業用或いは工業用サービスロボットを対象としても良く、複数の制御システムで構成されるメカトロシステ ムにおいて、各システム間でインタフェースをガイドに要求度の情報を付加 して検証の 合意を図る場合 に適用可能である。
【符号の説明】
【０２１７】
１００…車両制御システム（制御システム）
５００…設計支援システム
５１０…制御部
５１１…基礎アーキテクチャ作成部
５１２…初期アーキテクチャ作成部
５１３…影響分析部
５１４…機能安全要求整合判定部
５１５…標準アーキテクチャ更新部
５１６…詳細設計支援部
５１７…詳細設計結果検証部
５２０…記憶部
５２１…標準アーキテクチャＤＢ
５２２…基礎アーキテクチャＤＢ
５２３…初期アーキテクチャＤＢ
５２４…ハザード分析情報ＤＢ
５２５…機能安全要求情報ＤＢ
５３０…通信部
５４０…情報取得部
５５０…報知部
６００…端末装置
Ｍ…自車両（移動体）
Ｗ１…駆動輪
【図１】
2018140760.tif 000003
【図２】
2018140760.tif 000004
【図３】
2018140760.tif 000005
【図４】
2018140760.tif 000006
【図５Ａ】
2018140760.tif 000007
【図５Ｂ】
2018140760.tif 000008
【図６】
2018140760.tif 000009
【図７】
2018140760.tif 000010
【図８】
2018140760.tif 000011
【図９】
2018140760.tif 000012
【図１０】
2018140760.tif 000013
【図１１】
2018140760.tif 000014
【図１２】
2018140760.tif 000015
【図１３】
2018140760.tif 000016
【図１４】
2018140760.tif 000017
【図１５】
2018140760.tif 000018
【図１６】
2018140760.tif 000019
【図１７】
2018140760.tif 000020
【図１８】
2018140760.tif 000021
【図１９】
2018140760.tif 000022
【図２０】
2018140760.tif 000023
【図２１】
2018140760.tif 000024
【図２２】
2018140760.tif 000025
【図２３】
2018140760.tif 000026
【図２４】
2018140760.tif 000027
【図２５】
2018140760.tif 000028