JP2015099517A - 車両制御装置 - Google Patents

Abstract

【課題】本発明は、メモリ管理ユニットのようなハードウェアを用いなくても、ソフトウェアがアクセスする記憶領域が変更される場合にソフトウェアの再利用性を高めることができる車両制御装置を提供することを目的とする。【解決手段】本発明は、異なる安全度が設定される複数のソフトウェアと、前記複数のソフトウェアの安全度に対応して複数に区分され、ソフトウェアにより演算されるデータを記憶する安全度対応記憶領域と、前記安全度の高いソフトウェアによって演算されたデータを安全度の低いソフトウェアのアクセス用に記憶する共有記憶領域と、前記ソフトウェアの安全度に応じて、同一のデータを参照する際のアクセス先の記憶領域を切り換える切換部と、を備え、前記複数のソフトウェアは、前記同一のデータを参照するために前記切換部を呼び出す関数を含むことを特徴とする。【選択図】図１

Description

本発明は、車両制御装置に関する。

自動車、エレベータ、建設機械等の技術分野ではいわゆる組込みソフトウェアによって制御対象を制御する、組込み制御装置が用いられている。組込みソフトウェアは、従来の機械的機構や電気回路による方式に比べて柔軟かつ高度な制御が実現できることが利点として挙げられる。
このような組込み制御装置、例えば車両用の制御装置では、近年急速に高性能化が進むと共にシステムの複雑化が進み、予期せぬ誤動作が生じることが懸念されている。このため、安全装置やフェールセーフ機能の設置が機能安全規格（ＩＳＯ２６２６２）によって規定されている。

ＩＳＯ２６２６２では、自動車の安全要求と安全対策を指定する安全度の指標としてＡＳＩＬ（Ａｕｔｏｍｏｔｉｖｅ Ｓａｆｅｔｙ Ｉｎｔｅｇｒｉｔｙ Ｌｅｖｅｌ）が定められている。メーカは部品ごとに満たすべきＡＳＩＬを決定し、必要な安全機能および安全対策を設置する。一般的に、安全性に重大な影響がある部品ほど安全度が高く設定され高い安全性が保証されるが、開発コストも高くなる。そのため、メーカは高い安全性が求められる部品を精度良く見極め、それぞれの部品に適切な安全度を設定する必要がある。

ところで、一つの装置内で動作する複数のアプリケーションに対して異なる安全度が設定されると、ＡＳＩＬが異なるアプリケーションが、一つの統合ＥＣＵに混在する状態となってしまう。通常、ＡＳＩＬが異なるアプリケーションが同一のプラットフォームに混在する場合には、安全度が高いアプリケーション側の安全度水準に統一することが考えられる。

これに対し、機能安全規格では、アプリケーション同士が無干渉であり、互いの故障が伝播しあう可能性が無ければ（即ち、パーティショニングされていれば）異なる安全度水準を設けて良いとされている。そのため近年、同一の制御装置上に割り当てられた複数のソフトウェア間における故障伝播を防ぐ技術が必要とされている。

例えば特許文献１では、安全度の異なるソフトウェア間の独立性を保証する技術として、メモリ管理ユニット（ＭＭＵ）が有するメモリ保護技術を用いることで、ソフトウェアのメモリアクセス先を保護するリソースパーティショニング手法が提案されている。

特開２０１３−１４０４７７号公報

ところで、制御装置では、ソフトウェアの作成中や完成後にソフトウェアに設定される安全度が変更されるなどの事情により、参照するデータの内容は同じにもかかわらず、アクセスする記憶領域が変更となる場合がある。この場合、制御装置にメモリ管理ユニットが設けられていれば、安全度が変更されたソフトウェアのアクセス先をメモリ管理ユニットで変更することにより対応できるが、制御装置にメモリ管理ユニットが設けられない場合には、各ソフトウェアが禁止されている記憶領域にアクセスすることの無いようにプログラムを記述する必要がある。

従って、制御装置がメモリ管理ユニットを有しない場合には、ソフトウェアがアクセスする記憶領域の設定に変更があると、データを参照するためのアクセス先を変更するためにプログラムを書き換える必要があった。

しかし、これでは既に作成されたプログラムをそのまま利用することができない上に、プログラムの書き換え作業によってソフトウェアの不具合が生じるおそれがあり、ソフトウェアの再利用性が低いという問題がある。

そこで、本発明は、メモリ管理ユニットのようなハードウェアを用いなくても、ソフトウェアがアクセスする記憶領域が変更される場合にソフトウェアの再利用性を高めることができる車両制御装置を提供することを目的とする。

本発明は、異なる安全度が設定される複数のソフトウェアと、前記複数のソフトウェアの安全度に対応して複数に区分され、ソフトウェアにより演算されるデータを記憶する安全度対応記憶領域と、前記安全度の高いソフトウェアによって演算されたデータを安全度の低いソフトウェアのアクセス用に記憶する共有記憶領域と、前記ソフトウェアの安全度に応じて、同一のデータを参照する際のアクセス先の記憶領域を切り換える切換部と、を備え、前記複数のソフトウェアは、前記同一のデータを参照するために前記切換部を呼び出す関数を含むことを特徴とする。

本発明によれば、メモリ管理ユニットのようなハードウェアを用いなくても、ソフトウェアがアクセスする記憶領域が変更される場合にソフトウェアの再利用性を高めることができる。

実施例１に係るの車両制御装置のシステム構成を示す図。 実施例１に係るの車両制御装置のソフトウェアと安全度対応記憶領域および共有記憶領域を示す図。 実施例１に係る安全度情報テーブルを示す図。 実施例１に係る切換動作を示すフローチャート。 実施例２に係る車両制御装置のシステム構成を示す図。 実施例３に係る車両制御装置のシステム構成を示す図。。 実施例４に係る車両制御装置のシステム構成を示す図。 実施例５に係る車両制御装置のシステム構成を示す図。 その他の変形例に係る車両制御装置のシステム構成を示す図。

以下、図面を参照して本発明の実施形態を説明する。

図１は、実施例１の車両制御装置を示すシステム構成図である。

本実施例の車両制御装置１は、図１に示すように、安全度が異なる複数のソフトウェア１０１０１，１０２０１，１０３０１と、複数のソフトウェア１０１０１，１０２０１，１０３０１の安全度に対応して複数に区分され、ソフトウェアにより演算されるデータを記憶する安全度対応記憶領域１０４０１，１０４０２と、安全度の高いソフトウェアによって演算されたデータを安全度の低いソフトウェアのアクセス用に記憶する共有記憶領域１０４０３と、ソフトウェアの安全度に応じて、同一のデータを参照する際のアクセス先の記憶領域を切り換える切換部１０１０２，１０２０２，１０３０２とを有する。

なお、車両制御装置２は、自動車安全規格要求（ＩＳＯ２６２６２６）で規定されている安全要求レベル（ＡＳＩＬ）に基づき、ソフトウェアの安全度が区分されている。また、アクセスとは、記憶部１０４内のデータを呼び出す処理（Ｒｅａｄ）でも良いし、記憶領域内にデータを書き込む処理（Ｗｒｉｔｅ）でも良い。

また、車両制御装置１は、いわゆるマルチコアプロセッサであり、コアプロセッサと呼ばれる複数の制御部１０１，１０２，１０３と、記憶部１０４とを有し、各ソフトウェア１０１０１，１０２０１，１０３０１及び各切換部１０１０２，１０２０２，１０３０２は、それぞれ各制御部１０１，１０２，１０３に備えられる。

車両制御装置２は、各制御部１０１，１０２，１０３ごとに異なる安全度のソフトウェア１０１０１，１０２０１，１０３０１が搭載される。具体的には、制御部１０１のソフトウェア１０１０１及び制御部１０３のソフトウェア１０３０１は、高い安全度が設定されるＡＳＩＬソフトウェアであり、制御部１０２のソフトウェア１０２０１は、ＡＳＩＬソフトウェアよりも低い安全度が設定されるＱＭソフトウェアである。

記憶部１０４は、前記安全度対応記憶領域として、ＡＳＩＬ記憶領域１０４０１、ＱＭ記憶領域１０４０２とを有する。

ＡＳＩＬ記憶領域１０４０１は、ＡＳＩＬソフトウェア１０１０１に対応する記憶領域であり、ＡＳＩＬソフトウェア１０１０１が演算したデータやＡＳＩＬソフトウェア１０１０１が参照するデータが格納される。ＱＭ記憶領域１０４０２は、ＱＭソフトウェア１０２０１に対応する記憶領域であり、ＱＭソフトウェア１０１０１が演算したデータやＱＭソフトウェア１０１０１が参照するデータが格納される。

また、共有記憶領域１０４０３は、ＡＳＩＬソフトウェア１０１０１とＱＭソフトウェア１０２０１との間で共有されるデータを記憶する領域であり、具体的には、ＡＳＩＬソフトウェア１０１０１で演算されたデータをＱＭソフトウェア１０２０１でも利用するのに備えてＱＭソフトウェア１０２０１のために記憶する領域である。

図２は、本実施形態に係る車両制御装置１に搭載されたソフトウェア１０１０１，１０２０１および切換部１０１０２および記憶領域１０４０１を示したサンプルプログラムである。プログラム１０１０１０１，１０１０１０２，１０１０１０３は、高安全度が要求されているＡＳＩＬソフトウェア１０１０１に含まれ、プログラム１０２０１０１は、高安全度が要求されていないＱＭソフトウェア１０２０１に含まれる。

また、切換部１０１０２，１０２０２，１０３０２は、プログラム１０１０２０１によって実現されている。これにより、車両制御装置１がメモリ管理ユニットなどのハードウェアを備えているか否かにかかわらずソフトウェアによってパーティショニングを実現することができ、ソフトウェアの再利用性を向上させることも可能となる。

また、この車両制御装置１のソフトウェア１０１０１，１０２０１では、ａ〜ｇの値が制御に用いられる。このうち、ｃの値（即ち、データ）は、ＡＳＩＬソフトウェア１０１０１とＱＭソフトウェア１０２０１との間で共有される。具体的には、ａ，ｂ，ｄ〜ｇは変数であり、ｃは切換部１０１０２，１０２０２，１０３０２を呼び出す関数によって記述される。図２の例では、ｃは例えばｇｅｔ＿ｃ（ｇｅｔｆ＿ｉｄ（ｆ＿ｎａｍｅ））と記述される。

プログラム１０１０１０１は、ａ，ｂを用いてｃを演算するプログラム（例えばｃ＝ａ＋ｂ）であり、ＡＳＩＬ記憶領域１０４０１に演算結果であるｃのデータを格納する。上述のとおり、ｃのデータはＱＭソフトウェア１０２０１でも用いられることから、ＡＳＩＬソフトウェア１０１０１は、ＱＭソフトウェア１０２０１がｃのデータを利用可能とする必要がある。プログラム１０１０１０２は、このためにｃのデータをコピーするプログラムであり、ＡＳＩＬ記憶領域１０４０１に格納されているｃのデータを読み出し、共有記憶領域１０４０３にｃ＿ＱＭのデータとして格納する。このようにして、ＡＳＩＬ記憶領域１０４０１に格納されたｃのデータと共有記憶領域１０４０３に格納されたｃ＿ＱＭのデータを一致させる。

次に、ＡＳＩＬソフトウェアであるプログラム１０１０１０３は、ｄ，ｃを用いてｅを演算するプログラム（例えばｅ＝ｄ＋ｃ）である。また、ＱＭソフトウェアであるプログラム１０２０１０１は、ｆ，ｃを用いてｇを演算するプログラム（例えばｇ＝ｆ＋ｃ）である。

プログラム１０１０２０１は、ｃ含むプログラムが動作した際に呼び出されるプログラムであり、呼び出し元の安全度情報を参照して、呼び出し元に応じてデータの参照先を変更するプログラムである。具体的には、プログラム１０１０２０１は、呼び出し元の安全度情報に応じてデータの参照先を変更する条件判定文によって記述される。

呼び出し元の安全度情報の一例は、図３（Ａ）に示すように例えばソフトウェア又はプログラムごとに安全度を対応付けた情報である。図３（Ａ）は、ソフトウェアの安全度情報を格納した安全度情報テーブルである。安全度情報テーブル１０６０１は、ソフトウェア１０１０１，１０２０１，１０３０１のプログラムそれぞれが、高安全が要求されているＡＳＩＬソフトウェアまたは要求されていないＱＭソフトウェアのどちらに分類されているかの情報を保持している。切換部１０１０２，１０２０２，１０３０２は、この安全度情報テーブル１０６０１０の情報を利用することで、自身を呼び出したプログラムの安全度がＡＳＩＬかどうか、を判断できる。即ち、この方法は、プログラム１０１０２０１を呼び出したプログラムを呼出し元の関数名で判断する方法である。

ところで、車両制御装置１は、各制御部１０１，１０２，１０３ごとに異なる安全度のソフトウェア１０１０１，１０２０１，１０３０１が搭載される。従って、本実施例の場合には、動作する制御部が判明すればソフトウェアの安全度が分かる。従って、呼び出し元の安全度情報としては、図３（Ｂ）に示すように、各制御部に格納されるソフトウェアの安全度に基づいて決定される各制御部の固有情報（即ち、各制御部ごとに安全度を対応付けた情報）であってもよい。

具体的には、図３（Ｂ）の安全度情報テーブル１０６０２は、制御部１０１，１０２，２０３それぞれが、高安全が要求されている制御部または要求されていないＱＭ制御部のどちらに分類されているかの情報を保持しており、切換部１０１０２，１０２０２，１０３０２は、こちらの情報を用いた場合でも、自身を呼び出したプログラムの安全度がＡＳＩＬかどうか判断ができる。このようにすれば、安全度の情報を呼び出し元の機能ごとに対応付けて記憶する必要が無く、処理負荷の軽減やリソースの効率化を図ることができる。

プログラム１０１０２０１は、上記安全度情報に基づいて、プログラム１０１０１０３から呼び出された場合には、呼び出し元のプログラム１０１０１０３がＡＳＩＬソフトウェアであることを条件判定文にて判断し、ＡＳＩＬ記憶領域１０４０１にアクセスし、格納されたｃのデータをプログラム１０１０１０３に返す。これにより、プログラム１０１０１０３はｃのデータを得ることができる。

一方、プログラム１０１０２０１は、プログラム１０１０１０１から呼び出された場合には、呼出し元のプログラム１０２０１０１がＱＭソフトウェアであることを条件判定文にて判断し、共有記憶領域１０４０３にアクセスし、格納されたｃ＿ＱＭのデータを返す。これにより、プログラム１０２０１０１はｃと等しいデータｃ＿ＱＭのデータを得ることができる。

図４は、車両制御装置１の切換部１０１０２，１０２０２，１０３０２における処理手順を示すフローチャートである。ステップＳ１０１０２１から処理が始まる。ステップＳ１０１０２２で切換部１０１０２，１０２０２，１０３０２を呼び出したソフトウェアが安全度の高いソフトウェアかどうか（即ち、プログラム１０１０２０１を呼び出したプログラムがＡＳＩＬソフトウェアであるかどうか）を確認する。Ｙｅｓの場合はステップＳ１０１０２３に進み、Ｎｏの場合はステップＳ１０１０２４に進む。ステップＳ１０１０２３では、ＡＳＩＬ記憶領域１０４０１にアクセスする。ステップＳ１０１０２４では、共有記憶領域１０４０３にアクセスする。ステップＳ１０１０２５で処理を終了する。

なお、車両制御装置１は、アクセス先の共有記憶領域のアドレスがソフトウェアの実行中は固定される（即ち、変化しない）ように構成される。具体的には、変数ｃやｃ＿ＱＭとしてグローバル変数が使用される。このようにソフトウェアの実行中は変数ｃやｃ＿ＱＭのアドレスを不変とすることで、アクセスを迅速に行うことができるため、制御の迅速さが求められる車両制御に適している。また、ソフトウェアの実行中とは、例えば車両制御装置１の起動から動作終了までの期間である。

また、車両制御装置１は、切換部１０１０２，１０２０２，１０３０２は、ソフトウェア１０１０１，１０２０１，１０３０１等のアプリケーションソフトウェアと異なり、いわゆるミドルウェアとして実装される。これにより、ソフトウェア１０１０１，１０２０１，１０３０１の安全度が変更された場合には、ソフトウェア１０１０１，１０２０１，１０３０１のプログラムは変更する必要がなく、開発効率を向上させることができる。但し、切換部がいわゆるアプリケーションソフトウェアに組み込まれるものであってもよい。

以上のように、ＡＳＩＬソフトウェアであるプログラム１０１０１０３とＱＭソフトウェアであるプログラム１０２０１０１とは、異なる記憶領域にアクセスすることでパーティショニングを実現しつつも、ｃに関して同一のデータを得ることができる。即ち、ＱＭソフトウェアであるプログラム１０２０１０１からＡＳＩＬソフトウェアであるプログラム１０１０１０３への関与は存在しないため、ＱＭソフトウェアからＡＳＩＬソフトウェアへの故障伝播を防ぐことができる。これにより、同一の車両制御装置の中に異なる安全度のソフトウェアを混在させることができる。また、ＡＳＩＬソフトウェアであるプログラム１０１０１０３及びＱＭソフトウェアであるプログラム１０２０１０１はｃのデータを入手するため、同じ関数呼び出しにて切換部であるプログラム１０１０２０１を呼び出せるため、例えソフトウェアに要求される安全度に変更があったとしても、プログラムを書換える必要がない。つまり、メーカが割り当てたＡＳＩＬに変更があったとしても、既存のプログラムを再利用できるといった利点がある。

また、近年、機能安全規格とは別に、コスト削減を目的として制御装置の統合化に注目が集まっている。今までは複数のＥＣＵを用いて実現していた各アプリケーションを一つのＥＣＵに集約するいわゆるマルチコア化を図ることで、消費電力の低減や搭載スペースの削減に期待が寄せられている。本実施例によれば、ＥＣＵを統合化して異なる安全度のアプリケーションが混在して、パーティショニングが実現されることで、ＥＣＵ統合前の安全水準のままアプリケーションを集約することができるため、既存のソフトウェアの再利用が促進される。

図５は、本実施例の車両制御装置２を示すシステム構成図である。なお、他の実施例と共通する内容に関しては説明を割愛する。本実施例の車両制御装置２は、各制御部２０１，２０２，２０３のソフトウェア２０１０１，２０２０１，２０３０１がそれぞれ安全度の異なる複数のプログラムによって構成されている。この場合であっても、各プログラムが動作する際に切換部２０１０２，２０２０２，２０３０２が動作するソフトウェアの安全度を個別に判断し、記憶部２０４の対応する記憶領域２０４０１，２０４０２，２０４０３に適切にアクセスすることができる。

図６は、本実施例の車両制御装置３を示すシステム構成図である。なお、他の実施例と共通する内容に関しては説明を割愛する。本実施例の車両制御装置は、複数のソフトウェア３０１０１，３０２０１，３０３０１を格納する複数の制御部３０１，３０２，３０３を有し、切換部３０５は、複数の制御部３０１，３０２，３０３に対して一つ設けられる。切換部３０５は、制御部３０１，３０２，３０３から共通に利用されるライブラリのようなソフトウェアによって構成される。これによって、記憶部３０４の対応する記憶領域３０４０１，３０４０２，３０４０３に適切にアクセスすることができる。

図７は、本実施例の車両制御装置４を示すシステム構成図である。なお、他の実施例と共通する内容に関しては説明を割愛する。車両制御装置４は、この車両制御装置４は、いわゆるシングルコアプロセッサであり、複数のソフトウェア４０１０１，４０２０１，４０３０１と、複数のソフトウェア４０１０１，４０２０１，４０３０１に対して設けられる切換部４０２とを格納する制御部４０１が一つ設けられる。即ち、制御部４０１の中に切換部４０２が設けられる。これによって、記憶部４０４の対応する記憶領域４０４０１，４０４０２，４０４０３に適切にアクセスすることができる。

図８は、本実施例の車両制御装置５を示すシステム構成図である。なお、他の実施例と共通する内容に関しては説明を割愛する。車両制御装置５は、複数のソフトウェア５０１０１，５０２０１，５０３０１を格納する制御部５０１を有し、切換部５０５は、制御部５０１に対して設けられる。即ち、制御部５０１と切換部５０５とが一つ設けられ、制御部５０１の外部に切換部５０５が設けられる。

なお、本発明に係る車両制御装置は、上記実施形態の構成に限定されるものではなく、発明の趣旨を逸脱しない範囲内で種々の変更が可能である。

例えば、上記実施形態では、ソフトウェアの安全度が安全要求レベル（ＡＳＩＬ）に基づき区分される例について説明したが、これに限定されるものではなく、図９に示すように、何らかの安全度に基づいて区分されるものであれば本発明を適用することができる。

また、上記実施形態では、ソフトウェアの安全度としてＡＳＩＬ又はＱＭの２段階を設ける例について説明したが、これに限定されるものではなく、例えばソフトウェアをさらに細かくＡＳＩＬ−Ａ〜Ｄに区分し、これらに対応した安全度対応記憶領域を設けるものであっても良い。

また、上記実施形態では、切換部がソフトウェアの関数によって構成されるものを例に説明したが、これに限定されるものでなく、リンカスクリプトによって構成されるものであってもよい。

１…車両制御装置、１０１，１０２，１０３…制御部、１０１０１，１０２０１，１０３０１…ソフトウェア、１０１０２，１０２０２，１０３０２…切換部、１０４…記憶領域，１０４０１，１０４０２…安全度対応記憶領域、１０４０３…共有記憶領域

Claims (12)

1. 異なる安全度が設定される複数のソフトウェアと、
   前記複数のソフトウェアの安全度に対応して複数に区分され、ソフトウェアにより演算されるデータを記憶する安全度対応記憶領域と、
   前記安全度の高いソフトウェアによって演算されたデータを安全度の低いソフトウェアのアクセス用に記憶する共有記憶領域と、
   前記ソフトウェアの安全度に応じて、同一のデータを参照する際のアクセス先の記憶領域を切り換える切換部と、を備え、
   前記複数のソフトウェアは、前記同一のデータを参照するために前記切換部を呼び出す関数を含むことを特徴とする車両制御装置。
2. 前記複数のソフトウェアと、前記切換部とを格納する制御部を複数有することを特徴とする請求項１に記載の車両制御装置。
3. 前記複数のソフトウェアを格納する複数の制御部を有し、
   前記切換部は、前記複数の制御部に対して設けられることを特徴とする請求項１に記載の車両制御装置。
4. 前記複数のソフトウェアと、前記複数のソフトウェアに対して設けられる前記切換部とを格納する制御部を有することを特徴とする請求項１に記載の車両制御装置。
5. 前記複数のソフトウェアを格納する制御部を有し、
   前記切換部は、前記制御部に対して設けられることを特徴とする請求項１に記載の車両制御装置。
6. 前記安全度は、ＡＳＩＬに基づいて設定されることを特徴とする請求項１に記載の車両制御装置。
7. 前記アクセス先の共有記憶領域のアドレスがソフトウェアの実行中は固定されることを特徴とする請求項１に記載の車両制御装置。
8. 前記切換部は、ソフトウェアの関数により構成されていることを特徴とする請求項１に記載の車両制御装置。
9. 前記切換部は、リンカスクリプトにより構成されていることを特徴とする請求項１に記載の車両制御装置。
10. 前記切換部が前記ソフトウェアの安全度を判断するための安全度情報テーブルを有することを特徴とする請求項１に記載の車両制御装置。
11. 前記安全度情報テーブルは、前記各ソフトウェアごとの安全度に関する情報で構成されていることを特徴とする請求項１に記載の車両制御装置。
12. 前記複数のソフトウェアを格納する複数の制御部を有し、
    前記各制御部には、前記制御部ごとに同じ安全度のソフトウェアが格納され、
    前記安全度情報テーブルは、前記制御部に格納されるソフトウェアの安全度に基づいて決定される各コアの固有情報で構成されていることを特徴とする請求項１に記載の車両制御装置。