JP2006203392A - ソフトウェア無線装置及び車載情報システム - Google Patents

Abstract

【課題】車載システム上のソフトウェア無線機の仕様を変更するため、ソフトウェアのダウンロードとアップグレードを行うに当り、無線を利用したサービスを受けているユーザの利便性を損ねず、車載システムの誤動作を抑制する自動アップグレード方法を提示する。
【解決手段】車が利用されていない状態が最もアップグレードに好適であるため、ステップ６０４０と６０４１で、キーが抜かれているか否かを判断し、キーが抜かれていれば、ステップ６０４２で無線通信によりダウンロードを行う。その後、ステップ６０４３でソフトウェア無線機ＳＤＲＳとカーナビゲーションシステムＣＮＳの動作を停止し、ステップ６０４４と６０４５でアップグレードとテスト動作を行い、テスト結果が良好であるならば、ステップ６０４７でＳＤＲＳとＣＮＳの動作を再開する。
【選択図】 図６

Description

本発明は、ソフトウェアで無線装置の仕様を変更できるソフトウェア無線装置及び車載情報システムに関し、特に無線仕様をソフトウェアの変更によりアップグレードする技術に関する。

近年，情報処理機器の普及と高性能化に伴い，さまざまな無線通信方式が登場している。これらの無線通信方式に対して，無線通信に必要な送受信の信号処理をソフトウェアで実現し，ソフトウェアを交換することで，複数の異なる無線方式に対応するソフトウェア無線機が提案されている。

特許文献１では，オペレーティングシステムなどの基本ソフトを対象にして、移動中に迅速にダウンロードを行うことと、大衆向けに自動的なダウンロードを目指している。車に搭載されているソフトのバージョン情報を無線経由で取得し、これに基づきアップグレードの対象かどうかを判断する。また、車載システムの情報を無線経由で得て、アップグレードするソフトの動作条件に適合するか否かを判断する。これらの判断結果、アップグレードの条件に適合する時に新たなソフトをダウンロードする。これらの一連の判断と処理を、無線経由でサーバと端末側で協調して自動的に行っている。

特許文献２の発明は、端末装置のソフトウェアの更新や追加の実行前に、その更新や追加の是非についての適切な判断材料をユーザに与えることを目的としている。特許文献２のシステムでは、車両から情報センタへバージョンアップの要求とともに車両側の保有ソフト／ハード情報が送られる。この情報に基づいて、情報センタはバージョンアップ候補たる対象ソフトウェアを選び、対象ソフトウェアによって実現される機能を示すデモ画像を送信する。ユーザは、デモ画像を判断材料として、ダウンロードの許可を出す。さらに情報センタは、バージョンアップに伴うハードウェア変更の要否も車両に送る。この情報がユーザに提示され、ダウンロード実行の是非の判断材料とされる。

特開２００１−５６７１号公報 特開平１１−２７７４９号公報

ソフトウェア無線を車に搭載する時、ソフトウェアのアップグレード方法に関して、アップグレードが、移動体であり、コンピュータに不慣れな大衆向け製品である車においてなされるが故の課題が生じる。
（１）アップグレードの対象か、アップグレードが可能かという観点で、移動体の車内のソフトウェアバージョンと搭載されるシステムの情報をどう知るか？
（２）車走行中にサービスを受けるユーザの利便性をどう損ねずにアップグレードするか？
（３）車走行中に基本機能に誤動作が起こると、事故の要因にもなりうる。アップグレードによる誤動作をどう抑制するか？
（４）コンピュータに不慣れな大衆にどうソフトウェアの効果を認知させるか？
これらの課題は、ソフトウェア無線用のみならず、移動体を対象としたオペレーティングシステムなどの基本ソフトに共通の課題である。ただ、（４）の課題は移動体と基本ソフトに限定しなくても起こりうる課題である。

特許文献１に開示の方法は、ダウンロードやアップグレードに関する一連の判断と処理を、自動的に行うことにより、現在、受けているサービスを損ねないという点で、ユーザの利便性にもある程度配慮している。

しかし、特許文献１に開示の解決方法では、ユーザの利便性と誤動作の抑制という観点に、課題が残されている。特にソフトウェア無線装置の場合に、顕著となる。ここで、ダウンロードとは、ハードディスクなどの２次記憶媒体上に、ソフトウェアを格納するまでを指し、アップグレードとはこのソフトウェアがコンピュータ上で動作可能となるように、コンピュータをセットアップすることを指す。

まず、ユーザの利便性の観点で課題を述べる。ダウンロードとアップグレードは、数分から１０分程度の時間が必要となる。特にアップグレードは、コンピュータを一時停止させる必要があり、現在、利用しているサービスを一時中断しなければならない。携帯電話で用いられるような移動体用の無線は、基地局に端末の位置を知らせる必要があり、常時動作しているため、この動作を停止するにはユーザの利用状況を考慮しなければならない。ユーザの利便性を極力損なわないため、ユーザの利用状況を考慮してダウンロードとアップグレードを行うことが課題となる。

次に、誤動作の観点で課題を述べる。ソフトウェア無線で利用するソフトウェアは、ハードを直接制御する基本ソフトの範疇に属するため、正常動作を行うかどうかのテストを行ってから利用しないと、新たに追加される無線機能のみならず、他の機能も正常に動作しなくなるという誤動作に繋がる可能性がある。利便性と同様に、常時動作している移動体用の無線を対象にするときには、やはり、ユーザの利用状況を考慮して、誤動作を抑制するアップグレードを行うことが課題となる。

特許文献２には（１）、（４）の課題に関する記載はあるが、（２）、（３）の課題については配慮されていない。

本発明の目的は、サービスを享受しているユーザの利便性を損なうことなく、かつ車載システムの誤動作を抑制して、ソフトウェア無線機のアップグレードを移動体に対しても自動的に行うことができる、ソフトウェア無線装置を提供することにある。

本願において開示される発明のうち代表的なものの概要を簡単に説明すれば以下の通りである。

ソフトウェアで無線仕様を規定できる車載用の無線機と、該無線機を制御するコンピュータとを備えたソフトウェア無線装置であって、無線機仕様変更機能と、前記車の使用状態に関する情報を受取り前記コンピュータに通知する使用状態通知機能とを具備し、前記無線機仕様変更機能は、前記コンピュータにより実行され、前記車の使用状態が不使用のとき、該無線機の仕様を変更する処理を行うことを特徴とする、ソフトウェア無線装置。

サービスを享受しているユーザの利便性を損なうことなく、かつ車載システムの誤動作を抑制して、ソフトウェア無線機のアップグレードを移動体に対しても自動的に行うことができる。これにより、コンピュータに不慣れな大衆向けで移動体の製品にも、コンピュータの有効性を保つことができる。

以下、本発明による代表的な実施例を図面に従って詳細に説明する。なお、以下においては、同じ参照番号、記号は同じものもしくは類似のものを表わすものとする。

まず、本発明の実施例の前提となる基本的な考え方を述べる。本発明では、無線機の仕様の変更を車が不使用状態にある時に行うことにより、上記課題の解決を図るものである。これは、車が不使用の状態にあるとき、ユーザはサービスまたは無線を利用しておらず、しかも今後しばらくの間、例えば１０分程度の期間は利用しない可能性が高いと判断されるためであり、この不使用の状態の間に、無線ソフトの変更を行う。

ここで、車が不使用の状態にあるとは、車が実質的に使用状態にない、すなわち移動体としての車の走行状態やその準備段階になく、また、車の停止状態下であっても車載のアクセサリが使用されていない状態を意味する。車が不使用状態にある典型的な例は、エンジンキー(イグニッションキーとも言う)がキーシリンダから抜かれた状態である。なお、ユーザが無線機能付のエンジンキーを携帯している場合は、キーがキーシリンダに差し込まれていなくても、車が走行状態やその準備段階にあり、あるいは、車載のアクセサリが使用されていれば、車は使用状態にある。

他方、ドアロックキーのみが差し込まれ、エンジンキーはキーシリンダから抜かれた状態で、ユーザがルームランプの点灯した車室内に居る場合は、車は不使用状態であり、使用状態ではない。

以下、車の使用状態を検知して、無線ソフトのダウンロードとアップグレードを行う本発明のシステムの概要について述べる。なお、以下で特に区別しない場合、「キー」は、エンジンキーを意味するものとする。

まず、車載端末側のシステム構成として、全体制御を行うカーナビゲーションシステムＣＮＳ、ＣＮＳと協調して無線動作を行うソフトウェア無線システムＳＤＲＳ、および車の使用状態を検知する使用状態検知機能としてのキーが抜かれているかどうかを検知するキーセンサモジュールＫＳからなる。
次に、ＣＮＳ内の制御ソフトが保有する使用状態通知処理機能及び無線機仕様変更機能について説明する。ＣＮＳ内の制御ソフトは、使用状態検知機能に基き車が不使用状態である旨の通知を受けたとき、無線ソフトとテストプログラムをダウンロードする処理手順が必要となる。
第三番目に、制御ソフト内で、ソフトウェアのダウンロードの終了後、ＣＮＳとＳＤＲＳの無線動作を停止し、ソフトウェアのインストールとテスト動作を行う手順が必要となる。
最後に、制御ソフト内で、テストが良好に終了した後、ＣＮＳとＳＤＲＳの無線動作を再開する手順が必要となる。
以下、実施例に沿って、具体的に説明する。

図１は、車１００に搭載された情報システムを構成するテレマティクス端末１０４の一例を示すものである。特に、テレマティクス端末の一部をなすソフトウェア無線機（ＳＤＲＳ）１０６のシステム適用の例である。

ＳＤＲＳ１０６では、将来の無線仕様の変化や、無線基地局１０１や１０２の設置状況や電波状況により走行中に最適な無線仕様が変化したときに、この変化に柔軟に対処して無線仕様を切り替える必要がある。

切り替え対象の無線仕様としては、例えば、無線ＬＡＮ、ＥＴＣ（ＤＳＲＣ）、地上ＤＴＶ通信などがある。

以下では、まず、このＳＤＲＳを中心とするソフトウェア無線装置の構成と、アップグレードを行う好適なタイミングを述べ、次に、アップグレードを実現する全体のシステム構成と処理フローを述べる。

［1. ソフトウェア無線装置の構成］
図１において、テレマティクス端末１０４は、ホストコンピュータとしての機能を備えており、ソフトウェア無線機（ＳＤＲＳ）１０６の起動と終了を含むＳＤＲＳの制御を行う。テレマティクス端末１０４は、カーナビゲーションシステム（ＣＮＳ）１０７の、画像や音声などの情報処理をつかさどり、ＣＮＳ１０７に情報データを通信するために、ソフトウェア無線機（ＳＤＲＳ）１０６を利用する。また、ＣＮＳ１０７は、無線機の仕様を変更するための判断及び処理を実行する無線機仕様変更機能１０９を備えている。無線機仕様変更機能１０９(もしくはソフトウェア変更機能)は、コンピュータにおいてメモリ上にロードされ所定の手順を実行するプログラムにより実現されるものであり、車の使用状態に関する情報に基づいて、ＳＤＲＳの仕様を変更するか否かを判断し、変更が必要な場合は、車の不使用状態にＳＤＲＳの仕様を変更する処理を行う。

ＣＮＳ１０７とＳＤＲＳ１０６間のインタフェース１０８は、ＵＳＢなどの標準のデータ通信インタフェースを利用する。

ハードディスクドライバ（ＨＤＤ）１０５は、無線経由などで取得した情報データを記憶する。ＳＤＲＳ１０６のための無線ソフトやテストプログラムも、ここに一旦格納する。

キーセンサモジュール（ＫＳ）１０３はキーの状態を検知するモジュールで、キーの操作状態を検知するものであり、検知した信号をＡＤ変換するためのインバータ回路を含む。キーの操作状態としては、（ａ）キーがキーシリンダから抜かれた状態、（ｂ）キーが単にキーシリンダに差し込まれているだけの状態、（ｃ）キーが車載アクセサリ系の負荷とバッテリー間の電気的回路を閉成している状態、（ｄ）キーがアクセサリ系負荷及びエンジンのイグニッション系負荷とバッテリー間の各電気的回路を閉成している状態、（ｅ）キーがアクセサリ系負荷、イグニッション系負荷に加えてさらにエンジン起動系負荷ともバッテリー間の各電気的回路を閉成している状態、等が挙げられる。本実施例では、キーの操作状態が（ｂ）〜（ｅ）にあるとき、車が使用状態にあると判定する。

キーセンサモジュール（ＫＳ）１０３は、無線機能付のエンジンキーに関しても、同様にキーの操作状態を検知する機能を有する。

また、電気自動車の場合、キーの操作状態として、上記（ａ）、（ｂ）、（ｃ）に加えて、上記（ｄ）、（ｅ）に相当する走行用の発電電動機系負荷とバッテリー間の各電気的回路を閉成している状態を検知する機能蛾必要である。

図２は、ＳＤＲＳ１０６の内部構成を示すブロック図である。無線データは、アナログ処理部２０２を通ってディジタルデータに変換され、ディジタル処理を高性能に処理するダイナミックリコンフィギュラブル（ＤＲ）チップ２０３で行い、インタフェース１０８を通して、ＣＮＳ１０７に転送される。データを送信する場合には、この逆の経路を通る。ここで、ＤＲチップとは、ＡＬＵをアレイ状に並べた演算アクセラレータを中核とする信号処理向けの高性能チップである。

アナログ処理部２０２は、アンテナ２００、ＲＦ・ＩＦ回路２０１、アナログディジタルコンバータ（ＡＤＣ）・ディジタルアナログコンバータ（ＤＡＣ）からなる。ＡＤＣは受信時、ＤＡＣは送信時に利用する。

ディジタル処理部のＦＬＡＳＨ２０５は、各種のプログラムを格納しておくために利用する。

次に、無線機仕様変更機能１０９に関して、ＳＤＲＳ１０６が、ＣＮＳ１０７とどのような手順で無線データをやり取りするのかを、無線データを受信する場合を例にして、図３に従って以下に述べる。

図３に示す受信時には、ＳＤＲＳ１０６が1パケット受信とフレーム取出し３０１を行い、ＣＮＳ１０７に受信データを受け付けるよう要求する受信受付要求３０２を行う。ＣＮＳ１０７は、受信開始３００を行うため、Ｎａｖｉ−ＡｃｋをＳＤＲＳ１０６に転送する。これを受けて、ＳＤＲＳ１０６は、受信データ転送３０３を開始し、1フレームの受信データをＣＮＳ１０７に転送する。ＣＮＳ１０７では、受信受付３０４を開始する。ＳＤＲＳ１０６は，全ての受信データをＣＮＳ１０７に転送し終えたら、終わりを示すＥＮＤをＣＮＳ１０７に転送する。その後、ＣＮＳ１０７は、フレームの組立４０５を行うと同時に、送信局に返すＡＣＫ信号をＳＤＲＳ１０６に転送する（ＡＣＫ送信動作３０６）。ＡＣＫ送信は送信動作の一種であり、送信動作はここでは省略するが、受信動作の逆の過程をたどる。

以上、述べたように、ここで述べるソフトウェア無線装置は、１フレームの受信または送信をＳＤＲＳ１０６で行い、フレームの組み立てまたは分解はＣＮＳ１０７で行う。両者でソフトウェア無線装置を構成している。このような構成以外にも、ＳＤＲＳ１０６でフレームの組み立てまたは分解を行う構成も考えうるが、その場合にも、ＣＮＳ１０７はソフトウェア無線装置の起動・終了を指示や、状態監視を行うホストの役割を担う。このため、無線動作を行うときには、ＣＮＳ１０７が動作している必要があり、また、ＳＤＲＳ１０６の動作がＣＮＳ１０７の誤動作の原因にもなりうる。

［２．アップグレードを行うタイミング］
ここでは、図４に従い、ユーザの利便性を損ねず、誤動作を抑制するために、無線機仕様変更機能１０９が、ダウンロードとアップグレードを行うタイミングについて述べる。

図４で、図４（ａ）は、現在、ユーザがＣＮＳ１０７とＳＤＲＳ１０６を、サービスに利用しているか否かによって、ダウンロード（ＤＬ）とアップグレード（ＵＰ）に適合するタイミングを示す。図４（ｂ）は、図４（ａ）で示すＣＮＳ１０７とＳＤＲＳ１０６のサービスに対する利用状況（使用状態）は、車がどういう状態にある時に、起こりやすいかを示す。図４（ａ）から、ダウンロードとアップグレードに適するタイミングが得られ、図４（ｂ）から、適合するタイミングは、車がどういう状態にある時かがわかる。

図４の根拠を詳細に述べる前に、図４から得られる結論から述べると、ＤＬは、ＣＮＳ１０７が利用されているか否かに拘らず、ＳＤＲＳ１０６が利用されていない時（図４（ａ）で、ＳＤＲＳが not usedの列）が、実施するのに良いタイミングであるが、この状態が最も起こりうるのは車が利用されていな時（図４（ｂ）で、ＳＤＲＳが not usedの列で、かつＣａｒ ｓｔａｔｅがnot usedの行のセル）である。ＵＰは、ＣＮＳ１０７が利用されておらず、ＳＤＲＳ１０６が利用されていない時（図４（ａ）で、ＣＮＳがnot used、かつＳＤＲＳが not usedの列）が、実施するのに良いタイミングであるが、この状態が最も起こりうるのは車が利用されていない時（図４（ｂ）で、ＣＮＳがnot used、かつＳＤＲＳが not usedの列で、かつＣａｒ ｓｔａｔｅがnot usedの行のセル）である。

従って、ＤＬもＵＰも、車が利用されていない時を検知して、このタイミングで実施するのが好適だと言える。この検知を行って上で、ダウンロードはＳＤＲＳ１０６が動作していない状態か、ＣＮＳ１０７が動作していない状態、アップグレードは、ＣＮＳ１０７が動作していない状態を選択するのが好適である。

以下では、以上の結論を導出した図４の根拠を述べる。
まず、図４（ａ）を説明する。図４（ａ）で、usedは、現在、サービスを享受するために、ＣＮＳ１０７かＳＤＲＳ１０６を利用していることを示し、not usedは利用していないことを示す。但し、［１．］の項で述べたように、ＳＤＲＳ１０６を利用して無線動作を行っているときには、何らかの形でＣＮＳ１０７を利用しており、図４（ａ）で示すＣＮＳ１０７の利用状態は、無線動作以外での利用状態を示す。DLとUPの行に示す○は、ダウンロードまたはアップグレードを行うのに、ユーザの利便性と誤動作の抑止の観点で良いタイミングであることを示す。△は、良いタイミングとは言えないが、さほど悪影響を及ぼさないタイミングであることを示し、×は悪いタイミングであることを示す。

ダウンロード（ＤＬ）は、ＳＤＲＳ１０６が利用されていないときには、良いタイミングであり、利用されているときには、さほど良いタイミングでない。何故なら、ダウンロードは無線を利用することが必要となるため、ユーザの利便性を損ねるためである。一方、ＣＮＳ１０７が利用されているか否かには、タイミングの良否は依存しない。何故なら、無線動作に用いられるＣＮＳ１０７の処理量は少なく、無線を用いて、各種のデータをダウンロードをすることを前提に設計されていると考えられるため、無線用ソフトウェアのダウンロードが、他のサービスの阻害要因にはならないと想定して良いためである。

これに対して、アップグレード（ＵＰ）は、ＣＮＳ１０７とＳＤＲＳ１０６のいずれかが利用されている時には、悪いタイミングとなる。アップグレードを行うためには、インストールに引き続きテスト動作を行い、正常に動作することを確認する必要がある。これに対して、ソフトウェア無線の動作時には、｛１．｝の項で述べたように、ＳＤＲＳ１０６はもちろんのこと、ＣＮＳ１０７の動作も必要となるため、ユーザの利便性と誤動作の両面から考えて、現在、ＣＮＳ１０７とＳＤＲＳ１０６を用いて行っているサービスは停止させる必要がある。このため、これらを用いてサービスを行っている状況には、悪いタイミングとなる。

次に、図４（ｂ）を説明する。
車が使用状態にあるとき（Car Stateがusedの行＝ｉ〜iv）には、ＣＮＳ１０７が利用されているか否かにかかわらず、ＳＤＲＳ１０６が用いられているのが通常の状態（usually＝ｉ、iii）である。何故なら、車載上のサービスは、放送をはじめとして、無線を用いるテレマティクスサービスが主体であるためである。従って、ＳＤＲＳ１０６が利用されていない状態は、稀なケース（rare case＝ii、iv）だと言える。

次に、車が使用状態にないとき（Car Stateがun usedの行＝ｖ〜viii）を、ＣＮＳ１０７が動作しているときと、動作していなときに分けて述べる。
まず、ＣＮＳ１０７が動作している時(used)について述べる。この状況は、ＣＮＳ１０７を用いて何らかのサービスを受けている状況か、ＨＤＤ１０５にデータを格納する場合、稀に起こりうる。前者のサービスとして、鍵を閉じ込めたときに電子キーで自動的に解除するサービスが、現状考えうる。このサービスは、稀に起こりえるが、この時、移動体向けの無線を取り扱うＳＤＲＳ１０６は動作していない。後者は、無線動作は不要であるため、このときにもＳＤＲＳ１０６は動作していない。従って、ＣＮＳ１０７がusedのケースは、ＳＤＲＳ１０６がnot usedの時がrare case（＝vi）となる。一方、ＳＤＲＳ１０６がusedの時は、現状考えにくいが、将来、このようなケースに該当するサービスが出現する可能性を考慮して、very rare case（＝ｖ）とした。

次に、ＣＮＳ１０７が動作していないとき（not used）について述べる。この時、ＳＤＲＳ１０６が利用されているケース（not used）は、ＣＮＳ１０７が動作している時と同様に、現状のサービスでは考えにくいため、very rare case（＝vii）とした。一方、ＳＤＲＳ１０６が動作しないケース（not used）は、通常のケースでありusually（＝viii）となる。

ここで、上記で述べた２つの場合、即ち、ＣＮＳ１０７が動作しているケースと動作していないケースで、注意しておきたい点は、ＳＤＲＳ１０６がnot usedとは、何らかのサービスもしくは、その準備に使われていないという意味で、無線装置は、外部からの応答に備えて、常に通信動作のスタンバイ状態は保っている。例えば、位置を教えるという動作は、送信動作を伴うが、この動作を行っていないときでも、何らかのデータが到着したら受信動作は行う。

以上が、図４の根拠であり、［２．］項の最初に述べたように、図４から、ＤＬもＵＬも車が使用状態にないときに実施するのが、好適である。

従って、車が不使用状態にあるときを検知する手段が重要となり、この検知を含めて、ＤＬとＵＬを併せたアップグレードを実現するシステム構成と処理フローを［３．］以降で述べる。

［３．全体システム構成］
アップグレードの処理フローの前提となる、データセンタや車載の端末システムを含む全体システムの構成を図５に従い、以下に述べる。

アップグレードを実現する構成は、データセンタ（Ｄａｔａ ｃｅｎｔｅｒ）５００、バックボーン５０１、無線基地局５０２、および車載システム（Ｖｅｈｉｃｕｌａｒ Ｓｙｓｔｅｍ）５０３の４つに分かれる。データセンタ５００は、本発明で対象とするソフトウェアやコンテンツデータのサーバであり、ダウンロードするために基地局に送付する役目を持つ。バックボーン５０１は、光ファイバ網や公衆回線網などであり、サーバと各種無線基地局や大域的に端末間でデータのやり取りを行うための物理的な仲介の役目を持つ。無線基地局５０２は、無線データを、バックボーン５０１と各種無線端末間で送受信するための仲介役である。移動体の場合、無線端末の位置を常に監視して、最適な無線基地局５０２を通して、データを仲介する。車載システム５０３は、無線端末の一実現形態であるテレマティクス端末１０４と本発明のキーコンポーネントとなるキーセンサモジュール（ＫＳ）１０３からなる。

データセンタ５００は、ダウンロードする対象データを格納するデータベース（ＤＢ）５０００、ＤＢ５０００内のデータ転送を制御するＤＢサーバ（Ｓｅｒｖｅｒ）５００１、インターネットアドレス管理などインターネット用の制御を行うインターネットサーバ（ＩＮ Ｓｅｒｅｖｅｒ）５００２、５００２の制御に従いデータの送受信を行うインターネットプロトコルバージョン６ルータ（ＩＰｖ６ Ｒｏｕｔｅｒ）５００３からなる。

無線基地局５０２には、移動体向けに、各種ある。携帯電話用無線基地局（Ｍｏｂｉｌｅ Ｐｈｏｎｅ−ｂｓ）５０２０、無線ＬＡＮ基地局（ＷＬＡＮ−ｂｓ）、主に高速道路向けのＤＳＲＣ基地局（ＤＳＲＣ−ｂｓ）などである。これらの無線基地局の中から、移動体は、最適な無線を選択して、通信を行う。

車載システム５０３の内部構成と役割は、［１．］で述べたため、割愛する。アンテナ５０３０は、無線端末５０２と無線データのやり取りを行う。周波数帯域が異なるとアンテナは、複数本必要となるが、単数本か複数本かは、本発明の主題とは外れるので、本実施の形態では、単数本としている。

［４．アップグレードの処理フロー］
ＣＮＳ１０７の無線機仕様変更機能１０９によるアップグレードの処理フローを、図６から図１１に従い、以下に述べる。

図６は、車載システム５０３とそれ以外のデータセンタ５００、バックボーン５０１、および無線基地局５０２の役割分担を明示せず、全体の処理フローを示している。

図７から図９は、無線機仕様変更機能１０９によるアップグレード実施中にキー入力されたときを考慮した処理を詳細に示している。図７は、ダウンロード処理６０４２の詳細フローを示し、図８は、ダウンロードする無線ソフトのデータ構造を示す。図９は、キー入力されたときに実行する割り込み処理を示す。

図１０と図１１は、図６の処理フローを細分化して、車載システム５０３と、データセンタ５００の処理に分けて記載した。なお、バックボーン５０１と無線基地局５０２の処理は、本発明の主題とは外れるため、単なる無線データの通過経路と位置づけている。

［４．１ 全体処理フロー］
図６に従い、無線機仕様変更の全体処理フローを述べる。
まず、ステップ６００で、現在、車載システム５０３に搭載されている無線ソフトと車載システム５０３のバージョンを検知する。無線ソフトのバージョンの検知は、これから無線ソフトを新たなバージョンにアップグレードする必要があるか否かを判断するために行い、車載システム５０３のバージョンの検知は、新たなバージョンの無線ソフトを動作させるのに十分なハード仕様を持っているかどうかを判断するために行う。

ステップ６００で得られた無線ソフトのバージョンを元に、ステップ６０１では、バージョンが最新か否かを判断する。最新であればアップグレードの必要がないため、処理は終了する。

ステップ６０１の結果、無線ソフトのバージョンが最新でなければ、ステップ６００で得られた車載システム５０３のバージョンを元に、ステップ６０２で、アップグレードをするのにハード仕様が適合しているか否かを判断する。適合していなければ、ハードのバージョンアップをする必要があるため、ユーザは、ステップ６０３で、システムを含めたアップグレードをサービスステーションなどで実施する。

ステップ６０２の結果、車載システム５０３のバージョンがアップグレードに適合していれば、ステップ６０４で、無線ソフトのダウンロードとアップグレード（ＤＬ＆ＵＰ）を行う。以下で、ステップ６０４の内部処理ステップを述べる。

まず、ステップ６０４０で、対象車のキー状態を検知する。これは、［２．］の項で述べた条件に従い、車が利用されていないという条件をキーの状態で判断するためである。なお、車が不使用という状態を検出するために、キーの状態以外の手段で判断しても良いことは言うまでも無い。例えば、イグニッション系負荷やエンジン起動系負荷さらにはアクセサリ系負荷を統括的に制御するシステム例えばエンジンコントロールユニットの制御信号の有無を検出したり、あるいはこれらの制御信号の一部をそのまま利用することなども考えられる。本実施の形態では、最も確実な方法として、キーが入力あるいは操作されているか否かのキーの状態で検出する方法を利用する。

次に、ステップ６０４１で、キーが抜かれているかどうかを判断する。キーが差し込まれている状態では、車は利用中であると判断し、再びステップ６０４０に戻る。

第３番目に、ステップ６０４１でキーが抜かれていれば、車は利用されていないと判断し、ステップ６０４２で、無線ソフトとアップグレード結果をテストするテストプログラムをダウンロードする。この時、ダウンロードに先立ち、図４（ａ）でダウンロードに最適なタイミングであるＳＤＲＳ１０６が利用されていない時を選択する判断を設けることがさらに望ましいが、この判断はＣＮＳ１０７からのＳＤＲＳ１０７の状態の判断で、本実施例のＣＮＳ１０７がホストの役割を担っていることから容易に実現可能である。本発明の主題から外れるため、ここでは詳細な説明を省略する。

第４番目に、ステップ６０４３では、アップグレードするに先立ち、現在、ＳＤＲＳ１０６とＣＮＳ１０７が動作中であれば、動作を停止させる。この時、サービスに利用されていれば、ＣＮＳ１０７を利用してユーザに判断を問うステップがあれば、さらに望ましいが、本発明の主題から外れるため、ここでは省略する。但し、［２．］の最後の方で述べたように、外部からの応答に備えて、常に通信動作のスタンバイ状態を保つＳＤＲＳ１０６の動作は、サービスの準備動作であり、ユーザの判断は不要である。

第５番目に、ステップ６０４４で、アップグレードとテストを行う。具体的には、ＳＤＲＳ１０６とＣＮＳ１０７にインストールし、無線動作が正しく行われるか否かをテストする。

第６番目に、ステップ６０４５でテスト結果が良好であったか否かを判断し、失敗に終わった時には、ステップ６０４６で、ユーザに対策の指示を行う。対策には種々の方法が考えうるが、コンピュータに不慣れな大衆向きであることを勘案すると、サービスステーションに出向くよう指示するのが、妥当な方法であると思われる。

第７番目に、ステップ６０４５でテスト結果が良好であったときには、ステップ６０４７で、アップグレードのために停止させていたＳＤＲＳ１０６とＣＮＳ１０７の無線動作を再開させる。正確には、アップグレード前の状態に動作状態に戻す。

［４．２ キーが入力されたときの処理フロー］
ここでは、無線機仕様変更処理におけるダウンロードまたはアップグレード実施中に、ユーザーが車に戻りキー入力されたときに、どう対処するかを述べる。キー入力されたら、それまでの処理を出来る限り生かすことが望ましい。

まず、ダウンロード処理６０４２に関して、キー入力されたときの対処方法を（１）で述べ、次に、アップグレード処理６０４４に関してキー入力されたときの対処方法を（２）で述べる。最後に、ダウンロードとアップグレード共通に、キー入力されたときの割込みプログラムについて、（３）で述べる。
（１）ダウンロード処理中の対処方法
対処方法としては、ダウンロードを続行してアップグレードはしないか、ダウンロードを中止するかの二つに分かれる。アップグレードをしないのは、２．で図４をもとに述べたように、ソフトウェア無線は車走行中には、通常、利用されており、アップグレード動作により、現在利用している無線機が利用できなくなることにより、ユーザの利便性を損ねることを回避するためである。

前者は、無線ソフトのダウンロードの動作で、走行中の本来の動作の開始が遅れるため、ユーザはダウンロード終了まで、サービスが受けられないという欠点がある。無線ソフトのデータに加工を加えることなく、ダウンロードが行えるというメーカ側のメリットはあるが、ユーザの利便性に課題を残す。

後者には、次回キーが抜かれたときに最初からダウンロードをやり直す方法１と、今回ダウンロードをしたデータを生かして、次回は、次のデータからダウンロードする方法２が考えられる。方法１は、ダウンロードの続行と同じメーカ側のメリットがあるが、やり直しが生じるため、短時間の車の停止を頻繁に行うユーザは、ダウンロードまでの実時間が長くなり、新たな無線ソフトによるサービス享受が遅れる。やはり、ユーザの利便性に課題を残す。方法２は、無線ソフトをブロックに分割して、ブロックの番号によりどこまでダウンロードをしたかを記憶しておくことにより対処できる。メーカ側は、ダウンロードのために無線ソフトの加工が必要となるが、ユーザの利便性は向上する。以下では、方法２について、図７に従い詳細に述べる。

図７は、ダウンロード処理６０４２を、上記で述べた方法２に従い処理するフローを示す。ここでは、無線ソフトが図８に示すようにブロック分割され、ブロック毎にダウンロードする。ブロックの総数はＡＮ個である。無線ソフト以外のテストデータも同様にして処理可能である。

まず、図８に示すブロック分割されたデータ構造について述べる。このデータ構造は、データをブロック分割する構造の一例を示し、もちろん、他にもデータ構造はありうる。図８は、無線ソフトのプログラムを、ヘッダ８００から始まり、ブロック８０３に分割している。ヘッダ８００は、データの始まりを示すスタートフラグＳＴＲＴと全ブロック数を示すＡＮ８０２からなる。ヘッダの後は、ブロック８０３がＡＮで示す数だけ連続する。ブロック８０３は、ブロックの順番を示すＢＬＫＩＤ８０４とデータを示すＤＡＴＡ８０５からなる。ＤＡＴＡ８０５を連続するブロックの数だけ取り出して結合すると、無線ソフトのプログラムとなる。

図８の構造を持つデータは、初めてダウンロードをするときには、ヘッダから順番に送信されるが、次回からは、前回までにダウンロードを終了したブロック数ＬａｓｔＮの後ろのブロックから、データを送信する。

次に、図８のデータ構造を用いて、無線ソフトをブロック単位にダウンロードする処理フローを、図７に従い述べる。なお、図７には、キー入力されたときに、次回のダウンロードのために、今回のダウンロードがどのブロックまで行われたかを記憶する手段は記載されていない。この処理は、割込みプログラムとして、実現する。詳細は、後述の（３）で述べる。

ステップ７００：前回、ダウンロードが終了して、無線ソフトは実行可能な状態かどうかを判定する。この判定は、２次記憶装置に格納されているダウンロード終了を示すフラグＤＬＥが１か否かの判断で行う。１なら終了、１でなければ終了していないことを示す。

ステップ７０１：ダウンロードする全ブロック数ＡＮを２次記憶装置から取得する。前回までにヘッダ８００をダウンロードしていれば、ＡＮは設定されており、今回が初めてのダウンロードであればＡＮは０となっている。
ステップ７０２：ＡＮが０なら、ヘッダをダウンロードし、ＡＮを２次記憶に格納する。
ステップ７０３：前回ダウンロードしたブロック数ＬａｓｔＮを２次記憶から取得。現在、ダウンロードが終了したブロック番号ＰｒｅＮにＬａｓｔＮを格納し、ブロックのダウンロードの準備をする。
ステップ７０４：ＰｒｅＮがＡＮより小さいなら、まだダウンロードするブロックはあるため、ダウンロードを行う。そうでなければ、ダウンロードは終了し、ステップ７０８へ。

ステップ７０５：ダウンロードを行うサーバへ、現在までダウンロードし終わったブロック数ＰｒｅＮを送信し、次のブロックのダウンロードを要求する。
ステップ７０６：ブロック番号ＰｒｅＮ＋１のブロックのダウンロードを実施。
ステップ７０７：ＰｒｅＮを更新してＰｒｅＮ＋１にする。ダウンロードしたブロックからデータ部ＤＡＴＡ８０５を新たなＰｒｅＮと共に２次記憶に退避。次のブロックをダウンロードするために、再度ステップ７０４に戻る。

ステップ７０８：全てのブロックをダウンロードし終わったため、全てのブロックかのＤＡＴＡ８０５を結合して、元の無線ソフトのプログラムに戻して、２次記憶に格納。同時に、ダウンロード終了フラグＤＬＥを１にして、格納して、ダウンロード処理は終了する。
（２）アップグレード処理中の対処方法
対処方法としては、アップグレードを中止することである。何故なら、ダウンロードと異なり、アップグレードはその時のシステムの状態により、結果が異なることがあるためである。もちろん、システムが正常であれば同じ結果となるはずであり、結果が異なるのは、システムに異常が起こっているためであるが、異常がないかどうかも含めてテストを行う必要がある。

以上より、アップグレード処理中の対処としては、即時に中止して、次回、キーが抜かれた時には、最初からアップグレードをやり直す。アップグレード中止は、割り込み処理により行う。（３）にて述べる。
（３）キー入力時の割込み処理
ダウンロード処理６０４２とアップグレード処理６０４４を実行中に、キー入力された時には、処理を中断して、ダウンロード処理に対しては、次回、ダウンロードするために、今回のダウンロードがどのブロックまで行われたかを記憶する処理を行う必要がある。

割込みは、ＫＳ１０３から、カーナビＣＮＳ１０７への割込み通知で行われる。ここでは、本発明の主題と外れるため、詳細は割愛するが、１０７内には、図６や図７の処理を行うＣＰＵと、ＣＰＵに割り込みの通知を行う割込みコントローラが搭載されており、この機構を用いて、割込みプログラムは起動される。

図９に従い、割込みプログラムの処理フローを述べる。
ステップ９００：割込み通知を受けて、現在、ダウンロード処理６０４２を実行中か否かを判断する。プログラムカウンタを見ればこの判断は可能である。６０４２を実行中なら、ステップ９０１以降を処理する。

ステップ９０１：ダウンロード処理６０４２を実行中なら、次回のダウンロードに必要な情報ＬａｓｔＮを、ステップ７０７で２次記憶に格納したＰｒｅＮに更新する。

ステップ９０２：ＬａｓｔＮを２次記憶に退避し、次回のダウンロードに備える。
ステップ９０３：ダウンロード処理６０４２の強制終了。

ステップ９０５：現在、アップグレード処理６０４４を実行中か否かを判断する。６０４４を実行中なら、ステップ９０６以降を処理する。
ステップ９０６：アップグレード処理６０４４の強制終了。

ステップ６０４７：ＤＬ＆ＵＰのステップ６０４を実施前のシステム状態に復帰し、割込みプログラムを終了する。具体的には、各種レジスタを復帰して、ＳＤＲＳ１０６とＣＮＳ１０７のソフトウェア無線動作を再開する。

［４．３ 車載システムとデータセンタの処理］
ここでは、図１０と図１１に従い、図６で述べた無線機仕様変更処理の全体処理フローを、車載システム５０３とデータセンタ５００に分けて述べる。なお、データセンタ５００で、一連の処理を行うのは、主にＤＢサーバ５００１であるが、データの転送に当っては、当然、インターネットサーバ５００２とＩＰｖ６ルータ５００３も処理を行うが、これらの動作は、本発明の主題から外れるため割愛する。

まず、図６のステップ６００は、データセンタ５００からのバージョン問合せ６０００に応じて、車載システム７００内のＣＮＳ１０７がバージョンを通知して行う。ここでは、ＣＮＳ１０７が、無線ソフトと車載システムのバージョンを保持していることを前提としている。

次に、データセンタ５００で、ステップ６０１とステップ６０２の判断を行う。ここでは、両者の判断結果がＹｅｓであった場合を図示しているが、ステップ６０１の判断結果がＮｏであった場合には処理は終了し、ステップ６０２の結果がＮｏであった場合には、車載システムを保有するユーザに何らかの形でステップ６０３を行う指示をする。例えば、無線通知手段を用いる。

第３番目に、ステップ６０１とステップ６０２の結果、ダウンロードを行う対象であることが判別できれば、データセンタ５００は、ステップ６０４００で、ダウンロードを行ってよいか否かの可否を問い合わせる。

第４番目に、ステップ６０４００の問合せに応じて、ＣＮＳ１０７は、ステップ６０４０とステップ６０４１で、ＫＳ１０３のセンシング結果を得、キーが抜かれているか否かの判断を行う。キーが抜かれていれば、即ち、ステップ６０４１の結果が、Ｙｅｓであれば、ステップ６０４２０でデータセンタ側にダウンロード要求を送る。この時、４．１で述べたダウンロードに最適なタイミングとして、ＳＤＲＳ１０６が利用されていない時を選択する判断は、必要ならＣＮＳ１０７に問い合わせて、ダウンロードの前に行う。

第５番目に、ステップ６０４２０のダウンロード要求に応じて、データセンタ５００では、ステップ６０４２１にて無線ソフトとテストプログラムのダウンロードを行う。

第６番目に、車載システム５０３にダウンロードされたデータを、ＣＮＳ１０７は、ステップ６０４２２にて、端末側ダウンロードとして、ＨＤＤ１０５にデータを転送し、１０５にて、ステップ６０４２３により無線ソフト等のデータ更新を行う。ここまでで、ステップ６０４２は終了する。

最後に、アップグレードに先立ち、ステップ６０４３で、ＳＤＲＳ１０６とＣＮＳ１０７のソフトウェア無線動作を、一時停止する（図１１でＳＤＲＳ１０６が細い線の状態１１０１）。ここで停止とは、２．の最後の方で述べた通信動作のスタンバイ状態を保つ動作も含んで、ＳＤＲＳ１０６は完全に停止させ、ホストのＣＮＳ１０７のみが待ち受け状態になることを意味する。この時、４．１で述べたように、１０６か１０７がサービスに利用されており、ＣＮＳ１０７を利用してユーザに判断を問うステップが必要であれば、停止前に行う。

続いて、ステップ６０４４でアップグレードとテスト動作を行い（図１１で、ＳＤＲＳ１０６のテスト動作時は、点線の状態１１０２）、ステップ６０４５で、テスト結果が良好であれば、ステップ６０４７で、ソフトウェア無線動作を再開させる（図１１で、ＳＤＲＳ１０６が太線状態１１００が通常動作の状態）。

本実施例によれば、ユーザの利便性を損ねず、車載システムの誤動作を抑制して、自動的にソフトウェア無線機をアップグレードできる。

なお、以上述べた本発明の実施例では、無線機の仕様の変更処理を含む全体の制御をカーナビゲーションシステムＣＮＳで行うことにしているが、車載の情報システムを有し、ＣＮＳを含めたあるいはＣＮＳ以外の車の全体制御を行う機能を備えている場合には、その情報システムにより、無線機の仕様その他のソフトウエアの変更処理を行うようにしても良いことは言うまでもない。

本発明の一つの実施形態であるソフトウェア無線機ＳＤＲＳを含む車載システムの構成を示す図である。 本発明の一つの実施形態であるＳＤＲＳの構成図である。 本発明の一つの実施形態であるＳＤＲＳとＣＮＳとの受信実現手順を示すフロー図である。 本発明の一つの実施形態である無線ソフトのアップグレードを行うタイミングを選択するための図である。 本発明の一つの実施形態である全体システム構成図である。 本発明の一つの実施形態である無線ソフトのアップグレードを行う処理フロー図である。 本発明の一つの実施形態である無線ソフトのダウンロード処理６０４２の処理フローを示す図である。 本発明の一つの実施形態である無線ソフトをブロック毎にダウンロードためのデータ構造を示す図である。 本発明の一つの実施形態であるキー入力された時の割込みプログラムの処理フローを示す図である。 本発明の一つの実施形態である無線ソフトのアップグレードを行うデータセンタと車載システムの処理フローの前半部を示す図である。 本発明の一つの実施形態である無線ソフトのアップグレードを行うデータセンタと車載システムの処理フローの後半部を示す図である。

符号の説明

１０３…キーセンサモジュールＫＳ、１０４…テレマティクス端末、１０５…ハードディスクドライバＨＤＤ、１０６…ソフトウェア無線機ＳＤＲＳ、１０７…カーナビゲーションシステムＣＮＳ、２０２…ＳＤＲＳの前処理部、２０３…ダイナミックリコンフィギュラブル（ＤＲ）チップ、２０６…ＡＤＣ／ＤＡＣ、２０５…ＦＬＡＳＨロム、５００…データセンタ、５０１…バックボーン、５０２…無線基地局、５０３…車載システム。

Claims (20)

1. ソフトウェアで無線仕様を規定できる車載用の無線機と、該無線機を制御するコンピュータとを備えたソフトウェア無線装置であって、
   無線機仕様変更機能と、前記車の使用状態に関する情報を受取り前記コンピュータに通知する使用状態通知処理機能とを具備し、
   前記無線機仕様変更機能は、前記コンピュータにより実行され、前記車の使用状態が不使用のとき、該無線機の仕様を変更する処理を行うことを特徴とする、ソフトウェア無線装置。
2. 請求項１において、
   前記車の使用状態に関する情報は、前記車のキーが抜かれているか否かの情報であることを特徴とする、ソフトウェア無線装置。
3. 請求項１において、
   前記車の使用状態に関する情報は、前記車のアクセサリ系負荷もしくはイグニッション系負荷とバッテリー間の電気的な回路が開放されているか否かの情報であることを特徴とする、ソフトウェア無線装置。
4. 請求項１において、
   前記無線機仕様変更機能は、前記無線機の仕様を変更する前に、該無線機と前記コンピュータの動作を停止し、該仕様変更後、動作テストを行って良好に仕様変更が終了したことを確認後、該無線機と該ホストコンピュータの動作を再開させることを特徴とする、ソフトウェア無線装置。
5. 車載用の無線機と、該無線機の起動と終了を制御するコンピュータと、前記コンピュータにより実行されるソフトウェアを変更するソフトウェア変更機能と、前記車の使用状態に関する情報を受取り前記コンピュータに通知する使用状態通知処理機能とを具備し、
   前記ソフトウェア変更機能は、前記車の使用状態が不使用のとき、前記無線機を用いて前記ソフトウェアに関するデータをダウンロードする処理を行うことを特徴とする、ソフトウェア無線装置。
6. 請求項５において、
   前記使用状態に関する情報は、前記車のキーが抜かれているか否かの情報であることを特徴とする、ソフトウェア無線装置。
7. 請求項５において、
   前記無線機は、ソフトウェアで無線仕様を規定できる無線機であり、
   前記データは、前記無線機の仕様を変更するためのソフトウェアであることを特徴とする、ソフトウェア無線装置。
8. 請求項７において、
   前記ソフトウェア変更機能は、前記無線機の仕様を変更する前に、該無線機と前記コンピュータの動作を停止し、該仕様変更後、動作テストを行って良好に仕様変更が終了したことを確認後、該無線機と該ホストコンピュータの動作を再開させることを特徴とする、ソフトウェア無線装置。
9. 請求項７において、
   前記ソフトウェアが複数のブロック分割され、
   前記ソフトウェア変更機能は、ブロック毎に該ソフトウェアのダウンロードを実行することを特徴とする、ソフトウェア無線装置。
10. 請求項１において、
    前記ソフトウェアが複数のブロック分割され、
    前記無線機仕様変更機能は、ブロック毎に該ソフトウェアのダウンロードを実行することを特徴とする、ソフトウェア無線装置。
11. 請求項１において、
    前記無線機仕様変更機能は、前記車の使用状態が不使用のとき、前記無線機を用いて前記ソフトウェアに関するデータをダウンロードする処理を行い、該ダウンロード処理中に、前記車が使用状態となったときは、該ダウンロードを中止することを特徴とする、ソフトウェア無線装置。
12. 請求項１１において、
    前記無線ソフトは、複数のブロックに分割されており、
    前記無線機仕様変更機能は、前記ダウンロード処理中に前記無線ソフトのブロックの番号によりどこまでダウンロードをしたかを記憶し、次回は、次のデータからダウンロードすることを特徴とする、ソフトウェア無線装置。
13. 請求項１２において、
    ブロック分割されたデータは、データの始まりを示すスタートフラグＳＴＲＴと全ブロック数を示すＡＮ、ブロックの順番を示すＢＬＫＩＤ、及びデータを示す複数のＤＡＴＡからなり、
    該複数のＤＡＴＡを連続するブロックの数だけ取り出し結合することにより無線ソフトのプログラムが構成されることを特徴とする、ソフトウェア無線装置。
14. 請求項１において、
    前記無線機仕様変更機能は、前記車の使用状態が不使用のとき、前記無線機を用いてアップグレード処理を行い、
    該アップグレード処理中に、前記車が使用状態となったときは、該アップグレード処理を中止し、ソフトウェア無線動作を再開することを特徴とする、ソフトウェア無線装置。
15. 請求項１４において、
    前記無線機仕様変更機能は、割り込み処理により該アップグレードを中止し、実施前のシステム状態に復帰させ、
    中止した該アップグレードに関して、次回、前記車の使用状態が不使用となったときに、最初から該アップグレードをやり直すことを特徴とする、ソフトウェア無線装置。
16. ソフトウェアで無線仕様を規定できる無線機と、該無線機を制御するコンピュータとを備えた車載の情報システムであって、
    無線機仕様変更機能と、前記車の使用状態に関する情報を受取り前記コンピュータに通知する使用状態通知機能とを具備し、
    前記無線機仕様変更機能は、前記コンピュータにより実行され、前記車の使用状態が不使用のとき、該無線機の仕様を変更する処理を行うことを特徴とする、車載情報システム。
17. 請求項１６において、
    前記車の使用状態を検知し前記コンピュータに通知する使用状態通知機能を具備していることを特徴とする、車載情報システム。
18. 請求項１７において、
    前記使用状態通知機能は、前記車のキーが抜かれているかどうかを検知するセンサを含むことを特徴とする、車載情報システム。
19. ソフトウェアで無線仕様を規定できる車載用の無線機を制御するコンピュータを備えたソフトウェア無線装置において、情報を生成し出力するためのプログラムであって、コンピュータに、
    無線通信に必要な送受信の信号処理を行うために特定の仕様のソフトウェア無線機を構成する機能と、
    前記車の使用状態に関する情報を受取り、前記車の使用状態が不使用のとき、該ソフトウェア無線機の仕様を変更する処理を行う機能と、該変更処理中に前記車が使用状態となったときは、該変更処理を中止する機能、を実現させるためのプログラム。
20. ソフトウェアで無線仕様を規定できる車載用の無線機を制御するコンピュータを備えたソフトウェア無線装置において情報を生成し出力するためのプログラムであって、
    前記ソフトウェアは、複数のブロックに分割されており、
    コンピュータに、
    無線通信に必要な送受信の信号処理を行うために特定の仕様のソフトウェア無線機を構成する機能と、
    前記車の使用状態に関する情報を受取り、前記車の使用状態が不使用のとき、該ソフトウェア無線機の仕様を変更する処理を行う機能と、
    該変更処理中に、前記車が使用状態となったときは該変更処理を中止する機能と、
    前記変更処理中に前記ソフトウェアをどのブロックまでダウンロードしたかを記憶する機能、を実現させるためのプログラム。

Images