JP2016029547A

JP2016029547A - 実行モジュール生成装置、及び電子制御装置

Info

Publication number: JP2016029547A
Application number: JP2014151889A
Authority: JP
Inventors: 充弘谷; Mitsuhiro Tani
Original assignee: Denso Corp
Current assignee: Denso Corp
Priority date: 2014-07-25
Filing date: 2014-07-25
Publication date: 2016-03-03

Abstract

【課題】条件に応じて異なる処理を実行する際に、いずれの処理を実行する場合であっても、迅速に処理を実行し得る実行モジュールを生成すること。【解決手段】実行モジュール生成装置は、ソースコードＣ１１が第一モードで作動する第一アプリケーションのソースコードである場合、所定の処理に対応してリンクされるオブジェクトモジュールとして第一オブジェクトモジュールＣ１３を静的にリンクすることにより、第一の処理を所定の処理として実行する実行モジュールＣ３０を生成し、ソースコードＣ２１が第一モードとは異なる第二モードで作動する第二アプリケーションのソースコードである場合、所定の処理に対応してリンクされるオブジェクトモジュールとして第二オブジェクトモジュールＣ２３を静的にリンクすることにより、第一の処理とは異なる第二の処理を所定の処理として実行する実行モジュールＣ３０を生成する。【選択図】図４

Description

本発明は、実行モジュール生成装置、及び電子制御装置に関する。

車載用の電子制御装置（ＥＣＵ；Electronic Control Unit）のソフトウェアを標準化するための規格の一つとして、ＡＵＴＯＳＡＲ（Automotive Open System Architecture）において策定された規格（以下、ＡＵＴＯＳＡＲ規格と称する。）が知られている。

ＡＵＴＯＳＡＲ規格には、車載用リアルタイムＯＳ（以下、ＡＵＴＯＳＡＲ−ＯＳと称する。）が用意され、電子制御装置に搭載されるアプリケーションの作動モード（以下、アプリケーションモードとも称する。）として、二種類の作動モードが規定されている。一方の作動モードで作動するアプリケーションは、「trusted OS-Application（信頼できるアプリケーション）」と呼ばれ、他方の作動モードで作動するアプリケーションは、「non-trusted Application（信頼されないアプリケーション）」と呼ばれる。

また、ＡＵＴＯＳＡＲ−ＯＳの仕様では、サービスコール呼び出し時にサービスプロテクションを行うことが要求されている。この仕様に従えば、「trusted OS-Application」と「non-trusted OS-Application」とでは、それぞれで使用できるサービスコールに違いが生じる。例えば、同じサービスコールであっても、「trusted OS-Application」から呼び出せば正常に処理が実行されるのに対し、「non-trusted OS-Application」から呼び出すとエラーになるなど、その挙動に違いがある。

ＯＳ（Operating System）が提供するＡＰＩ（Application Programming Interface）を使って、ＯＳが有する所定の機能を利用した際に、正常終了するケースとエラーとなるケースがある例としては、例えば特許文献１に示されているような処理を挙げることができる。特許文献１の図８に示されている処理では、ＡＰＩ経由で所定の処理が呼び出された際に、呼び出される側のルーチンで動的にエラー判定を行う（Ｓ２１，Ｓ２２，Ｓ１２，Ｓ１３）。そして、その判定結果に応じて、所定の処理を正常に実行する場合もあれば（Ｓ２４，Ｓ１４）、所定の処理を実行することなく異なる挙動を示す場合（例えばエラー処理を実行する場合）もある（Ｓ２３，Ｓ１５）。

特開２０１２−１９４８４５号公報

しかしながら、上述の例のように、呼び出された側のルーチンにおいて、当該ルーチンが呼び出されるたびに動的にエラー判定を実行するように構成すると、そのような判定を行うために必要な処理も含めて、相応の処理時間を要する。そのため、このような判定手法を採用することは、サービスコールの実行速度が低下する要因の一つとなり得る。

例えば、ＡＵＴＯＳＡＲ規格に準拠したアプリケーションの場合、呼び出された側のルーチン（サービスコール側。）において、「trusted OS-Application」なのか「non-trusted OS-Application」なのかを判定したい場合には、まず、実行中タスクＩＤを取り出す処理を行う。そして、取り出したＩＤに基づいてタスク構成情報テーブルを参照し、アプリケーションの作動モードを取り出す処理を行う。その上で、その作動モードから「trusted OS-Application」なのか「non-trusted OS-Application」なのかを判断し、その判断結果に対応する処理を実行することになる。

しかし、これら一連の処理を実行するには、ＲＯＭの読み出しや、テーブル内を参照するためのオフセット計算などが必要になる。そのため、これら一連の処理を実行するために相応の処理時間を要し、これがサービスコールを呼び出したときの応答速度を低下させる原因になる。

以上のような事情から、条件に応じて異なる処理を実行する際に、いずれの処理を実行する場合であっても、迅速に処理を実行し得る実行モジュールを生成可能な実行モジュール生成装置と、そのような実行モジュールを備えた電子制御装置を提供することが望ましい。

以下に説明する実行モジュール生成装置は、ソースコードをコンパイルしてオブジェクトモジュールを生成し、生成されたオブジェクトモジュールを含む複数のオブジェクトモジュールを静的にリンクすることによって実行モジュールを生成可能に構成されている。

この実行モジュール生成装置は、ソースコード中に所定の処理の実行を要求する処理ステップが記述されている場合に、ソースコードが第一モードで作動することが規定された第一アプリケーションのソースコードである場合には、所定の処理に対応してリンクされるオブジェクトモジュールとして第一オブジェクトモジュールを静的にリンクする。これにより、第一の処理を所定の処理として実行する実行モジュールを生成する。

一方、この実行モジュール生成装置は、ソースコード中に所定の処理の実行を要求する処理ステップが記述されている場合に、ソースコードが第一モードとは異なる第二モードで作動することが規定された第二アプリケーションのソースコードである場合には、所定の処理に対応してリンクされるオブジェクトモジュールとして第二オブジェクトモジュールを静的にリンクする。これにより、第一の処理とは異なる第二の処理を所定の処理として実行する実行モジュールを生成する。

このように構成された実行モジュール生成装置によって実行モジュールを生成すれば、ソースコードが、第一アプリケーション又は第二アプリケーションいずれのソースコードであるのかに応じて、ソースコード中に記述された所定の処理が同一であっても、その所定の処理に対応してリンクされるオブジェクトモジュールが変わる。

そのため、例えば、第一オブジェクトモジュールについては、第一アプリケーションから呼び出されることを前提にして作成されたルーチンを備えていればよい。また、例えば、第二オブジェクトモジュールについては、第二アプリケーションから呼び出されることを前提にして作成されたルーチンを備えていればよい。

よって、第一オブジェクトモジュール及び第二オブジェクトモジュールのいずれにおいても、第一アプリケーション又は第二アプリケーションのいずれから呼び出されたのかを判断する処理は不要となる。また、そのような判断に必要な情報を取得する処理も不要となる。したがって、それらの処理が不要となる分だけ、各アプリケーションで所定の処理の実行を要求した場合の処理速度を向上させることができる。

また、第一オブジェクトモジュール及び第二オブジェクトモジュールのそれぞれについては、条件に応じて分岐する処理が不要となる。そのため、各オブジェクトモジュールの試験時にはテストケースを削減でき、予期しない処理へ分岐するおそれがない分だけ処理の信頼性向上を図ることもできる。

また、以下に説明する電子制御装置は、ＯＳと、ＯＳの制御下で作動する複数のアプリケーションが組み込まれている。複数のアプリケーションには、第一モードで作動することが規定されたアプリケーションと、第一モードとは異なる第二モードで作動することが規定されたアプリケーションとが含まれる。

これらの各アプリケーションは、ソースコードをコンパイルしてオブジェクトモジュールを生成し、生成されたオブジェクトモジュールを含む複数のオブジェクトモジュールを静的にリンクすることによって生成された実行モジュールによって構成される。

この実行モジュールは、ソースコード中に所定の処理の実行を要求する処理ステップが記述されている場合に、第一アプリケーションのソースコードである場合には、所定の処理に対応してリンクされるオブジェクトモジュールとして第一オブジェクトモジュールを静的にリンクすることにより、第一の処理を所定の処理として実行する実行モジュールとして構成される。

一方、ソースコード中に所定の処理の実行を要求する処理ステップが記述されている場合に、ソースコードが第二アプリケーションのソースコードである場合には、所定の処理に対応してリンクされるオブジェクトモジュールとして第二オブジェクトモジュールを静的にリンクすることにより、第一の処理とは異なる第二の処理を所定の処理として実行する実行モジュールとして構成されている。

このように構成された電子制御装置によれば、第一アプリケーション及び第二アプリケーションそれぞれの実行モジュールが、上述のように構成されている。そのため、各アプリケーションのソースコードレベルでは、同様に所定の処理を実行する旨の記述がなされていても、実行モジュールレベルでは、第一アプリケーションの場合は第一の処理が実行され、第二アプリケーションの場合は第二の処理が実行される。

しかも、各アプリケーションで第一の処理又は第二の処理を実行するに当たって、第一アプリケーションの場合は上述のような第一オブジェクトモジュールをリンクし、第二アプリケーションの場合は上述のような第二オブジェクトモジュールをリンクする構成とされている。

そのため、第一オブジェクトモジュール及び第二オブジェクトモジュールのいずれにおいても、第一アプリケーション又は第二アプリケーションのいずれから呼び出されたのかを判断する処理は不要となる。また、そのような判断に必要な情報を取得する処理も不要となる。したがって、それらの処理が不要となる分だけ、各アプリケーションで所定の処理の実行を要求した場合の処理速度を向上させることができる。

なお、特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本発明の技術的範囲を限定するものではない。

電子制御装置（ＥＣＵ）の構成を示すブロック図。電子制御装置に搭載されるソフトウェアの構成を示す説明図。実行モジュール生成装置の構成を示すブロック図。第一実施形態における実行モジュールの生成手順を示す説明図。第二実施形態における実行モジュールの生成手順を示す説明図。ソースコードの一例を示す説明図。

次に、上述の実行モジュール生成装置、及び電子制御装置について、例示的な実施形態を挙げて説明する。
（１）第一実施形態
［電子制御装置の構成］
図１に示すように、車載用の電子制御装置（Electronic Control Unit；以下、ＥＣＵと略称する。）１は、ＣＰＵ２、ＲＯＭ３、ＲＡＭ４、及びＣＡＮ（Controller Area Network）コントローラ５など、周知のハードウェアを備えている。これらＣＰＵ２、ＲＯＭ３、ＲＡＭ４、及びＣＡＮコントローラ５は、内部バス６を介して相互に接続されている。また、ＣＡＮコントローラ５はＣＡＮ８に接続されている。これにより、ＥＣＵ１は、ＣＡＮ８を介して他のＥＣＵと通信可能に構成されている。

また、ＥＣＵ１には、ソフトウェアとして、ＡＵＴＯＳＡＲ−ＯＳ、及びＡＵＴＯＳＡＲ−ＯＳの制御下で作動する各種アプリケーションプログラムが搭載されている。これらのソフトウェアは、ＲＯＭ３に記憶されている。ＥＣＵ１の作動時には、ＲＯＭ３に記憶されたソフトウェアがＣＰＵ２によって読み出され、ＣＰＵ２が各種プログラムに従って所定の処理を実行することにより、ＥＣＵ１においてＯＳ及びアプリケーションが機能する状態になる。

［電子制御装置上で作動するソフトウェアの一例］
上述のＥＣＵ１の作動時には、まず上述のＡＵＴＯＳＡＲ−ＯＳが作動する。そして、ＡＵＴＯＳＡＲ−ＯＳの制御下で、各種アプリケーションが作動する。ＡＵＴＯＳＡＲ−ＯＳの制御下で作動するアプリケーションは、既に言及した通り、「trusted OS-Application」と、「non-trusted OS-Application」に分類される。各アプリケーションが「trusted OS-Application」又は「non-trusted OS-Application」のいずれに該当するのかは、ソースコードレベルで規定されている。そのため、各アプリケーションの作動モードが、各アプリケーションの作動時に動的に変更されることはない。

「trusted OS-Application」と「non-trusted OS-Application」とでは、それぞれにおいて使用できるサービスコールやサービスコールの動作が異なる。一例を挙げれば、サービスコールの一つに該当する「ShutdownOS」については、「trusted OS-Application」からから呼び出されたときの動作と「non-trusted OS-Application」から呼び出されたときの動作が異なる。これは、ＡＵＴＯＳＡＲ−ＯＳの規格として取り決められている事項である。

そのため、第一実施形態では、上記ＥＣＵ１に搭載されるアプリケーションの実行モジュールを生成する際に、「trusted OS-Application用カーネル」と「non-trusted OS-Application用カーネル」とをそれぞれ用意し、各アプリケーション単位で一次リンク作業を行っている。この一次リンク作業により、サービスコールの呼び出しについて解決を行った後、更に二次リンク作業を行うことにより、他のＯＳカーネルとのリンクも行うことで、ＥＣＵ１に搭載される実行モジュール群が生成される。

例えば、図２に示す事例の場合、オブジェクトモジュール１１は、「trusted OS-Application」のソースコードをコンパイルすることによって生成される。このソースコード中で「ShutdownOS」を呼び出している場合、一次リンク作業を行う際には、「trusted OS-Application」用のカーネルモジュール１２を含むカーネルライブラリが選択されて、一次リンク作業が行われる。

一方、オブジェクトモジュール１３は、「non-trusted OS-Application」のソースコードをコンパイルすることによって生成される。このソースコード中で「ShutdownOS」を呼び出している場合、一次リンク作業を行う際には、「trusted OS-Application」用のカーネルモジュール１４を含むカーネルライブラリが選択されて、一次リンク作業が行われる。

そして、これら各アプリケーションの一次リンクを終えた後に、更に二次リンク作業を行うことで、他のＯＳカーネルモジュール１５とのリンクも行われる。「trusted OS-Application」のオブジェクトモジュール１１において「ShutdownOS」が呼ばれた場合は、「trusted OS-Application」に組み込まれた「trusted OS-Application」用のカーネルモジュール１２が機能し、それに伴ってＯＳカーネルモジュール１５も機能する。一方、「non-trusted OS-Application」のオブジェクトモジュール１３において「ShutdownOS」が呼ばれた場合は、「non-trusted OS-Application」に組み込まれた「non-trusted OS-Application」用のカーネルモジュール１４が機能する。この場合は、「non-trusted OS-Application」に対する機能制限に起因して、ＯＳカーネルモジュール１５に対する情報伝達は実施されず、ＯＳカーネルモジュール１５は機能しない。

このように「trusted OS-Application」用のカーネルモジュール１２と、「non-trusted OS-Application」用のカーネルモジュール１４とを、それぞれ個別に用意して各アプリケーションに組み込んでおけば、カーネルモジュール１２については、必ず「trusted OS-Application」に組み込まれることが保証される。また、カーネルモジュール１４については、必ず「non-trusted OS-Application」に組み込まれることが保証される。

したがって、カーネルモジュール１２の内部処理では、「trusted OS-Application」から呼び出されたのか否かを判定する処理や、その判定結果に応じて処理を分岐させる対応を行わなくても、常に「trusted OS-Application」から呼び出された場合に対応する処理を実施すればよい。また、カーネルモジュール１４の内部処理では、「non-trusted OS-Application」から呼び出されたのか否かを判定する処理や、その判定結果に応じて処理を分岐させる対応を行わなくても、常に「non-trusted OS-Application」から呼び出された場合に対応する処理を実施すればよい。

［実行モジュール生成装置の構成］
図３に示すように、実行モジュール生成装置として機能するパーソナルコンピュータ（Personal Computer；以下ＰＣと略称する。）２０は、制御部２１、記憶部２２、表示部２３，及び入力部２４など、周知のハードウェアを備えている。制御部２１は、周知のＣＰＵ２１１、ＲＯＭ２１２、ＲＡＭ２１３、及びインターフェース部２１４などを備える。

記憶部２２は、ハードディスク装置などによって構成され、各種プログラムや各種データを記憶可能に構成されている。表示部２３は、液晶ディスプレイ装置などによって構成され、制御部２１から出力される映像信号に基づいて各種情報を表示可能に構成されている。入力部２４は、ポインティングデバイス（例えばマウス等。）やキーボードなどによって構成され、利用者が所定の入力操作を実施することで、その入力操作に応じた入力信号を制御部２１が入力可能に構成されている。

また、このＰＣ２０には、ソフトウェアとして、ＯＳ、及びＯＳの制御下で作動する各種アプリケーションプログラムがインストールされている。アプリケーションプログラムとしては、後述するコンパイラ３１やリンケージエディタ３２（図４参照。）がインストールされている。

［実行モジュールの生成手順の一例］
ＰＣ２０において、「trusted OS-Application」の実行モジュールを生成する場合は、図４に示すように、ソースコードＣ１１をコンパイラ３１によってコンパイルすることにより、オブジェクトモジュールＣ１２が生成される。このコンパイル工程において、コンパイラ３１はソースコードＣ１１を解析し、ソースコードＣ１１が「trusted OS-Application」又は「non-trusted OS-Application」のいずれのソースコードなのかを判断する。ここでは、ソースコードＣ１１が「trusted OS-Application」のソースコードであると判断され、その旨の情報が所定の記憶領域に記録される。

続いて、リンケージエディタ３２は、コンパイル工程で記録された情報に基づき、「trusted OS-Application」用のカーネルライブラリ３３を選択する。カーネルライブラリ３３には、ＡＵＴＯＳＡＲ−ＯＳによって提供される機能に対応する様々なオブジェクトモジュールが登録されている。上述の「ShutdownOS」に対応するオブジェクトモジュールなどもカーネルライブラリ３３に含まれている。

コンパイル工程で生成されたオブジェクトモジュールＣ１２中で、「ShutdownOS」を呼び出している場合、リンケージエディタ３２は、コンパイル工程で生成されたオブジェクトモジュールＣ１２と、選択したカーネルライブラリ３３に登録された「ShutdownOS」のオブジェクトモジュールＣ１３とをリンクする。これにより、一次リンク済みオブジェクトモジュールＣ１４が生成される。

一方、ＰＣ２０において、「non-trusted OS-Application」の実行モジュールを生成する場合は、ソースコードＣ２１をコンパイラ３１によってコンパイルすることにより、オブジェクトモジュールＣ２２が生成される。このコンパイル工程においても、コンパイラ３１はソースコードＣ２１を解析し、ここではソースコードＣ２１が「non-trusted OS-Application」のソースコードであると判断されて、その旨の情報が所定の記憶領域に記録される。

続いて、リンケージエディタ３２は、コンパイル工程で記録された情報に基づき、「non-trusted OS-Application」用のカーネルライブラリ３４を選択する。カーネルライブラリ３４には、ＡＵＴＯＳＡＲ−ＯＳによって提供される機能に対応する様々なオブジェクトモジュールが登録されている。上述の「ShutdownOS」に対応するオブジェクトモジュールなどもカーネルライブラリ３４に含まれている。

ただし、先に説明したカーネルライブラリ３３は、「trusted OS-Application」用であったのに対し、カーネルライブラリ３４は、「non-trusted OS-Application」用である。そのため、カーネルライブラリ３３，３４それぞれに上述の「ShutdownOS」に対応するオブジェクトモジュールＣ１３，Ｃ２３が含まれているものの、それらの処理内容は異なるものとされている。

コンパイル工程で生成されたオブジェクトモジュールＣ２２中で、「ShutdownOS」を呼び出している場合、リンケージエディタ３２は、コンパイル工程で生成されたオブジェクトモジュールＣ２２と、選択したカーネルライブラリ３４に登録された「ShutdownOS」のオブジェクトモジュールＣ２３とをリンクする。これにより、一次リンク済みオブジェクトモジュールＣ２４が生成される。

カーネルライブラリ３３に含まれるオブジェクトモジュールＣ１３と、カーネルライブラリ３４に含まれるオブジェクトモジュールＣ２３は、双方とも「ShutdownOS」という同じシンボル（関数名）に対応付けられている。しかし、これらのカーネルライブラリ３３，３４は、同時に併用されることはなく、いずれか一方がリンケージエディタ３２によって択一的に選択されて、アプリケーション単位でオブジェクトモジュール間のリンクが解決される。したがって、「trusted OS-Application」のリンク時にカーネルライブラリ３４が利用されることはなく、「non-trusted OS-Application」のリンク時にカーネルライブラリ３３が利用されることもない。

このようにして生成された一次リンク済みオブジェクトモジュールＣ１４，Ｃ２４は、更にリンケージエディタ３２によって、「trusted OS-Application」及び「non-trusted OS-Application」の双方で共用されるＯＳカーネルモジュール３５ともリンクされ、二次リンク済み実行モジュール群Ｃ３０が生成される。なお、二次リンク済み実行モジュール群Ｃ３０は、ＥＣＵ１が備えるＲＯＭ３（例えば、フラッシュメモリやマスクＲＯＭ等。）に書き込まれる。

［第一実施形態の効果］
以上説明したようなＥＣＵ１によれば、サービスコール（例えば、「ShutdownOS」。）が呼び出された際に、呼び出し元が「trusted OS-Application」であれば、「trusted OS-Application」に対応した処理を実行することができる。また、呼び出し元が「non-trusted OS-Application」であれば、「non-trusted OS-Application」に対応した処理を実行することができる。

しかも、サービスコールが呼び出された際に、「trusted OS-Application」に対応した処理を実行するか、「non-trusted OS-Application」に対応した処理を実行するかは、静的解析、静的な設計により、リンケージエディタ３２によるリンク時に確定している。そのため、呼び出されたサービスコール側では、「trusted OS-Application」から呼び出されたのか、「non-trusted OS-Application」から呼び出されたのかを、動的に判断する必要がなく、そのような判断に必要な情報を取得する必要もなく、判断結果に応じて異なる処理を実行する必要もない。

したがって、これらアプリケーションモードの判定にかかる処理を省略することができ、その分だけ迅速に処理を完了させることができる。よって、サービスコールの実行速度が低下するのを避けつつ、確実にアプリケーションごとのアプリケーションモードに応じた機能を実現することができる。また、それぞれのサービスコールのプログラムについては、判定条件が少ないシンプルな処理手順になるので、その分だけテストケースの削減ができ、カーネル自体の信頼性向上にもつながる。

なお、電子制御装置１に搭載される各アプリケーションは、製造段階やメンテナンス段階でフラッシュメモリやマスクＲＯＭ等に書き込まれるが、実行時にプログラムが書き換えられることはない。そのため、各アプリケーションが「trusted OS-Application」であるのか「non-trusted OS-Application」であるのかが動的に変化することはなく、各アプリケーションの作動モードは、コンパイル段階における静的な解析で特定することができる。

上記実施形態では、このような特徴を利用し、「ShutdownOS」に対応するオブジェクトモジュールＣ１３，Ｃ２３をアプリケーションモードごとに用意し、これらをリンク段階で静的にリンクすることで、動的なアプリケーションモード判定等を省略してパフォーマンス向上している。しかも、「ShutdownOS」に対応するオブジェクトモジュールＣ１３，Ｃ２３をアプリケーションモードごとに用意することで、サービスコール呼び出し時のサービスプロテクションを適切に実施することができ、これにより、信頼性の確保をも実現することができる。

（２）第二実施形態
次に、第二実施形態について説明する。なお、第二実施形態は、基本的な構成は第一実施形態と同様であるため、共通する構成については説明を省略し、相違点を中心に説明する。

［実行モジュールの生成手順の一例］
上述の第一実施形態では、「trusted OS-Application」用のカーネルライブラリ３３と、「non-trusted OS-Application」用のカーネルライブラリ３４とを、それぞれ個別に用意し、リンケージエディタ３２によるリンク工程で、カーネルライブラリ３３，３４のいずれかを選択していた。

これに対し、以下に説明する第二実施形態では、ソースコードのコンパイル時に、「trusted OS-Application」又は「non-trusted OS-Application」のいずれに対応するソースコードなのかに応じて、選択的にソースコードの一部を置換することで、所期の実行モジュールを生成している。

より詳しく説明すると、第二実施形態において、「trusted OS-Application」の実行モジュールを生成する場合は、図５に示すように、ソースコードＣ４１をコンパイラ３１によってコンパイルすることにより、オブジェクトモジュールＣ４２が生成される。このコンパイル工程において、コンパイラ３１はソースコードＣ４１を解析し、ソースコードＣ４１が「trusted OS-Application」用のソースコードであれば、所定の関数を呼び出す記述を「trusted OS-Application」用の関数を呼び出す記述に置換する。また、「non-trusted OS-Application」の実行モジュールを生成する場合は、ソースコードＣ５１をコンパイラ３１によってコンパイルすることにより、オブジェクトモジュールＣ５２が生成される。このコンパイル工程において、コンパイラ３１はソースコードＣ５１を解析し、ソースコードＣ５１が「non-trusted OS-Application」用のソースコードであれば、所定の関数を呼び出す記述を「non-trusted OS-Application」用の関数を呼び出す記述に置換する。

本実施形態において、これら所定の関数に対する置換処理は、図６に示すような、インライン機能を利用したプロトタイプ宣言をソースコード中に加えることによって実現している。図６に示すソースコードは、ソースコードＣ４１，Ｃ５１それぞれをコンパイルする際に、各ソースコードＣ４１，Ｃ５１中に書き加えられる。

図６に示すソースコードは、サービスコールの一つに該当する「ActivateTask」を呼び出す記述が各ソースコードＣ４１，Ｃ５１中に含まれている場合に、「trusted OS-Application」用のソースコードＣ４１であれば、「ActivateTask」を呼び出す記述を「ActivateTask＿Trust」を呼び出す記述に置換する。また、「non-trusted OS-Application」用のソースコードＣ５１であれば、「ActivateTask」を呼び出す記述を「ActivateTask＿NonTrust」を呼び出す記述に置換する。

各ソースコードＣ４１，Ｃ５１中に図６に示すソースコードが含まれる場合、図６に示すソースコード中の１行目に記述されている、Ｃ９９規格のインライン機能を利用したプロトタイプ宣言により、「ActivateTask」を呼び出す記述は、２行目から１７行目が展開される。

また、図６に示すソースコード中、４行目にある記述は、定数であるべき「ＴａｓｋＩＤ」が定数であり、かつ、「ＴａｓｋＩＤ」が最小値「ＭＩＮＴＡＳＫＩＤ」以上であり、かつ、「ＴａｓｋＩＤ」が最大値「ＭＡＸＴＡＳＫＩＤ」以下である場合に真（ｔｒｕｅ）となる。「ＴａｓｋＩＤ」は、アプリケーションごとに割り当てられた定数であるため、上記４行目の条件が真となるか否かは、コンパイラ３１によるコンパイル時静的解析機能を利用して判断することができる。

また、図６に示すソースコード中、６行目にある記述は、アプリケーションモードを判断する記述であり、ソースコードが「trusted OS-Application」のソースコードである場合に真（ｔｒｕｅ）となる。「アプリケーションモード」も、アプリケーションごとに決められて、それに対応する定数が記述されているため、上記６行目の条件が真となるか否かは、コンパイラ３１によるコンパイル時静的解析機能を利用して判断することができる。

そのため、「trusted OS-Application」用のソースコードＣ４１をコンパイルする際には、上述のコンパイル時静的解析機能による判断の結果、８行目の記述だけがコンパイル対象として残される。これにより、「ActivateTask」を呼び出す記述は「ActivateTask＿Trust」を呼び出す記述に置換されてからコンパイルされて、オブジェクトモジュールＣ４２が生成されることになる。また、「non-trusted OS-Application」用のソースコードＣ５１をコンパイルする際には、上述のコンパイル時静的解析機能による判断の結果、１１行目の記述だけがコンパイル対象として残される。これにより、「ActivateTask」を呼び出す記述は「ActivateTask＿NonTrust」を呼び出す記述に置換されてからコンパイルされて、オブジェクトモジュールＣ５２が生成されることになる。

なお、ソースコードに何らかの問題があって、上記４行目の条件が真とならなかった場合には、１５行目の記述だけがコンパイル対象として残される。これにより、「ActivateTask」を呼び出す記述は「Static＿analysys＿error」を呼び出す記述に置換され、この場合も、オブジェクトモジュールは生成される。ただし、「Static＿analysys＿error」は、カーネルライブラリ３７等に登録されていないため、リンク時にエラーとなる。したがって、「Static＿analysys＿error」のリンクエラーが発生した場合は、そのことをもって、コンパイル対象となったソースコードに何らかの問題があるものと判断でき、間違ったアプリケーションの作成が防止される。

さて、上述のようなコンパイル工程により、オブジェクトモジュールＣ４２，Ｃ５２が生成されたら、続いて、リンケージエディタ３２は、オブジェクトモジュールＣ４２と、カーネルライブラリ３７に登録された「ActivateTask＿Trust」のオブジェクトモジュールＣ４３とをリンクする。また、リンケージエディタ３２は、オブジェクトモジュールＣ５２と、カーネルライブラリ３７に登録された「ActivateTask＿NonTrust」のオブジェクトモジュールＣ５３とをリンクする。オブジェクトモジュールＣ４３，Ｃ５３は、第一実施形態の場合とは異なり、異なるシンボル（関数名）が付与されているので、同じカーネルライブラリ３７内に共存させることができる。さらに、これらのオブジェクトモジュールは、リンケージエディタ３２により、「trusted OS-Application」及び「non-trusted OS-Application」の双方で共用されるＯＳカーネルモジュール３５ともリンクされ、リンク済み実行モジュール群Ｃ６０が生成される。なお、リンク済み実行モジュール群Ｃ６０は、ＥＣＵ１が備えるＲＯＭ３（例えば、フラッシュメモリやマスクＲＯＭ等。）に書き込まれる。

［第二実施形態の効果］
第二実施形態において例示した手法で、第一実施形態で例示したようなＥＣＵ１を構成しても、第一実施形態と全く同様の作用、効果を奏し、サービスコールが呼び出された際に、「trusted OS-Application」に対応した処理を実行するか、「non-trusted OS-Application」に対応した処理を実行するかは、静的解析、静的な設計により、リンケージエディタ３２によるリンク時に確定している。そのため、呼び出されたサービスコール側では、「trusted OS-Application」から呼び出されたのか、「non-trusted OS-Application」から呼び出されたのかを、動的に判断する必要がなく、そのような判断に必要な情報を取得する必要もなく、判断結果に応じて異なる処理を実行する必要もない。

［他の実施形態］
以上、実行モジュール生成装置、及び電子制御装置について、例示的な実施形態を挙げて説明したが、本発明は、上述の例示的な実施形態に限定されるものではなく、本発明の技術的思想を逸脱しない範囲内において、様々な形態で実施することができる。

例えば、上記各実施形態では、「ShutdownOS」、「ActivateTask」といった特定のサービスコールを例示しながら技術的特徴を説明したが、上記以外の各種システムコールや標準ライブラリを組み込む場合でも、本技術を適用することができる。

また、上記第一実施形態では、リンク工程を一次リンクと二次リンクに分けて実施する例、上記第二実施形態では、リンク工程を一次リンクと二次リンクには分けずに実施する例を示したが、上記第二実施形態の場合でも、上記第一実施形態同様に、リンク工程を複数段階に分けて実施してもよい。

また、上記各実施形態では、電子制御装置１に搭載されるＯＳの例として、ＡＵＴＯＳＡＲ−ＯＳを例示したが、ＯＳがＡＵＴＯＳＡＲ−ＯＳであるか否かは任意である。例えば、ＡＵＴＯＳＡＲ−ＯＳに対して更に仕様を付加した規格のＯＳや、逆に、ＡＵＴＯＳＡＲ−ＯＳの一部の仕様を削除した規格のＯＳなどにおいても、本技術を適用することができる。あるいは、ＡＵＴＯＳＡＲ−ＯＳとは全く異なる規格のＯＳに対しても、本技術を適用することができる。

また、上記実施形態における１つの構成要素が有する機能を複数の構成要素として分散させたり、複数の構成要素が有する機能を１つの構成要素に統合させたりしてもよい。例えば、コンパイラ３１は、複数のプロセスが協働してコンパイラ３１として機能するように構成されていてもよい。

また、上記実施形態の構成の少なくとも一部を、同様の機能を有する公知の構成に置き換えてもよい。また、上記実施形態の構成の一部を省略してもよい。また、上記実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加又は置換してもよい。なお、特許請求の範囲に記載した文言のみによって特定される技術思想に含まれるあらゆる態様が本発明の実施形態である。

また、上述した電子制御装置の他、当該電子制御装置を構成要素とするシステム、当該電子制御装置としてコンピュータを機能させるためのプログラム、このプログラムを記録した媒体など、種々の形態で本発明を実現することもできる。

１…電子制御装置（ＥＣＵ）、２…ＣＰＵ、３…ＲＯＭ、４…ＲＡＭ、５…ＣＡＮコントローラ、６…内部バス、８…ＣＡＮ、２０…ＰＣ（実行モジュール生成装置）、２１…制御部、２１１…ＣＰＵ、２１２…ＲＯＭ、２１３…ＲＡＭ、２１４…インターフェース部、２２…記憶部、２３…表示部、２４…入力部、３１…コンパイラ、３２…リンケージエディタ、３３，３４，３７…カーネルライブラリ、３５…カーネルモジュール。

Claims

ソースコード（Ｃ１１，Ｃ２１，Ｃ４１，Ｃ５１）をコンパイルしてオブジェクトモジュール（Ｃ１２，Ｃ２２，Ｃ４２，Ｃ５２）を生成し、前記生成されたオブジェクトモジュールを含む複数のオブジェクトモジュール（Ｃ１２，Ｃ１３，Ｃ２２，Ｃ２３，Ｃ４２，Ｃ４３，Ｃ５２，Ｃ５３）を静的にリンクすることによって実行モジュール（Ｃ３０，Ｃ６０）を生成可能に構成されており、
前記ソースコード中に所定の処理の実行を要求する処理ステップが記述されている場合に、前記ソースコードが第一モードで作動することが規定された第一アプリケーションのソースコード（Ｃ１１，Ｃ４１）である場合には、前記所定の処理に対応してリンクされるオブジェクトモジュールとして第一オブジェクトモジュール（Ｃ１３，Ｃ４３）を静的にリンクすることにより、第一の処理を前記所定の処理として実行する実行モジュールを生成する一方、前記ソースコードが前記第一モードとは異なる第二モードで作動することが規定された第二アプリケーションのソースコード（Ｃ２１，Ｃ５１）である場合には、前記所定の処理に対応してリンクされるオブジェクトモジュールとして第二オブジェクトモジュール（Ｃ２３，Ｃ５３）を静的にリンクすることにより、前記第一の処理とは異なる第二の処理を前記所定の処理として実行する実行モジュールを生成するように構成されている
実行モジュール生成装置。
請求項１に記載の実行モジュール生成装置であって、
前記ソースコードが、前記第一アプリケーションのソースコードであるのか、前記第二アプリケーションのソースコードであるのかを、前記ソースコード中の記述に基づいて解析し、その解析結果に応じて、前記第一オブジェクトモジュール又は前記第二オブジェクトモジュールのいずれか一方を静的にリンクするように構成されている
実行モジュール生成装置。
請求項２に記載の実行モジュール生成装置であって、
前記ソースコード（Ｃ４１，Ｃ５１）をコンパイルする段階で、前記解析を行って、その解析結果に応じて、前記ソースコード中に記述されている前記所定の処理の実行を要求する処理ステップを、前記第一の処理の実行を要求する処理ステップ又は前記第二の処理の実行を要求する処理ステップのいずれか一方に置換してから、前記置換されたソースコードに基づいてオブジェクトモジュール（Ｃ４２，Ｃ５２）を生成することにより、前記生成されたオブジェクトモジュールが前記第一オブジェクトモジュール（Ｃ４３）又は前記第二オブジェクトモジュール（Ｃ５３）のいずれか一方が静的にリンクされるオブジェクトモジュールとなるように構成されている
実行モジュール生成装置。
請求項２に記載の実行モジュール生成装置であって、
前記ソースコード（Ｃ１１，Ｃ２１）をコンパイルする段階で、前記解析を行って、その解析結果に応じて、前記第一アプリケーションのソースコード（Ｃ１１）であった場合には、前記所定の処理に対応してリンクされるオブジェクトモジュールとして前記第一オブジェクトモジュール（Ｃ１３）が含まれるライブラリ（３３）を選択する一方、前記第二アプリケーションのソースコード（Ｃ２１）であった場合には、前記所定の処理に対応してリンクされるオブジェクトモジュールとして前記第二オブジェクトモジュール（Ｃ２３）が含まれるライブラリ（３４）を選択し、前記生成されたオブジェクトモジュールと前記選択されたライブラリ内のオブジェクトモジュールとを含む複数のオブジェクトモジュールを静的にリンクするように構成されている
実行モジュール生成装置。
ＯＳ（Operating System）と、前記ＯＳの制御下で作動する複数のアプリケーションが組み込まれており、
前記複数のアプリケーションは、第一モードで作動することが規定されたアプリケーションと、前記第一モードとは異なる第二モードで作動することが規定されたアプリケーションとを含み、各アプリケーションは、ソースコード（Ｃ１１，Ｃ２１，Ｃ４１，Ｃ５１）をコンパイルしてオブジェクトモジュール（Ｃ１２，Ｃ２２，Ｃ４２，Ｃ５２）を生成し、前記生成されたオブジェクトモジュールを含む複数のオブジェクトモジュール（Ｃ１２，Ｃ１３，Ｃ２２，Ｃ２３，Ｃ４２，Ｃ４３，Ｃ５２，Ｃ５３）を静的にリンクすることによって生成された実行モジュール（Ｃ３０，Ｃ６０）によって構成され、
前記実行モジュールは、前記ソースコード中に所定の処理の実行を要求する処理ステップが記述されている場合に、前記第一アプリケーションのソースコード（Ｃ１１，Ｃ４１）である場合には、前記所定の処理に対応してリンクされるオブジェクトモジュールとして第一オブジェクトモジュール（Ｃ１３，Ｃ４３）を静的にリンクすることにより、第一の処理を前記所定の処理として実行する実行モジュールとして構成され、前記ソースコードが前記第二アプリケーションのソースコード（Ｃ２１，Ｃ５１）である場合には、前記所定の処理に対応してリンクされるオブジェクトモジュールとして第二オブジェクトモジュール（Ｃ２３，Ｃ５３）を静的にリンクすることにより、前記第一の処理とは異なる第二の処理を前記所定の処理として実行する実行モジュールとして構成されている
電子制御装置。