JP2023551005A - パラメータ構成方法、装置、およびシステム - Google Patents

Abstract

本出願は、パラメータ構成方法、装置、およびシステムを提供し、インテリジェント車両の分野に関する。本出願で提供される解決策では、組み込みデバイスのサービス層は、ハードウェア層のハードウェアリソースパラメータを直接取得し、ハードウェアリソースパラメータをAUTOSAR開発ツールに送信しえ、これにより、AUTOSAR開発ツールは、構成ファイルおよび実行可能ファイルを生成する。開発者は、開発ツールにハードウェアリソースパラメータを手動で入力する必要がない。したがって、パラメータ構成効率が効果的に改善されることができ、誤ったパラメータ構成の確率が低減されることができ、アプリケーション開発効率がさらに改善されることができる。組み込みデバイスは、インテリジェント車両、コネクティッド車両、または新エネルギー車両などの車両に適用されることができる。

Description

本出願は、2020年11月27日に出願された「パラメータ構成方法、装置、およびシステム」と題された中国特許出願第202011364749．6号に基づく優先権を主張し、その全体は参照によりここに組み込まれる。

本出願は、インテリジェント車両の分野に関し、特に、パラメータ構成方法、装置、およびシステムに関する。

自動車オープンシステムアーキテクチャ（automotive open system architecture、AUTOSAR）は、自動車産業向けに開発されたオープンな標準化されたソフトウェアアーキテクチャである。

アプリケーションがAUTOSARに基づいて開発される場合、ユーザは、リモート端末（Telnet）もしくはセキュアシェル（secure shell、ssh）などのプロトコルを用いてデバイスにリモート接続し、コマンドラインを入力することによってデバイスのハードウェア形態を決定してもよいし、またはユーザは、ハードウェアマニュアルをチェックしてデバイスのハードウェア形態を決定してもよい。次に、ユーザは、ハードウェア形態に基づいて、AUTOSAR構成ツールにハードウェアリソースパラメータを手動で入力しうる。構成ツールは、ユーザによって入力されたハードウェア構成パラメータに基づいて記述ファイルを生成してもよく、AUTOSAR生成ツールが、記述ファイルに基づいて構成ファイルおよび実行可能ファイルをさらに生成してもよい。

しかしながら、前述の開発プロセスでは、ユーザがハードウェアリソースパラメータを手動で入力する必要があるため、パラメータ構成効率が低い。

本出願は、手動パラメータ構成によって引き起こされる低いパラメータ構成効率の課題を解決するためのパラメータ構成方法、装置、およびシステムを提供する。

一態様によれば、パラメータ構成方法が提供され、AUTOSARを用いる組み込みデバイスに適用される。組み込みデバイスは、ハードウェア層、サービス層、およびアプリケーション層を含む。本方法は、サービス層が、ハードウェア層のハードウェアリソースパラメータを取得し、ハードウェアリソースパラメータをAUTOSAR開発ツールに送信することを含む。ハードウェアリソースパラメータは、実行可能ファイルおよび構成ファイルを生成するためにAUTOSAR開発ツールによって使用され、実行可能ファイルおよび構成ファイルはハードウェア層において記憶されることができる。次に、サービス層は、構成ファイルに基づいて実行可能ファイルを動作させることができる。

サービス層はハードウェア層のハードウェアリソースパラメータを直接取得し、ハードウェアリソースパラメータをAUTOSAR開発ツールに送信することができるため、開発者はハードウェアリソースパラメータを開発ツールに手動で入力する必要がない。したがって、パラメータ構成効率が効果的に改善されることができ、誤ったパラメータ構成の確率が低減されることができる。

任意選択で、構成ファイルはリソース管理ポリシーを含む。本方法は、サービス層が、リソース管理ポリシーに基づいて、ハードウェア層に含まれるハードウェアリソースの動作ステータスを調整することをさらに含みうる。

サービス層は、構成ファイル内のリソース管理ポリシーに基づいてハードウェアリソースを柔軟にスケジュールすることができる。

任意選択で、リソース管理ポリシーは、ターゲットハードウェアリソースの識別子および第1のプロパティを含んでもよく、第1のプロパティは、ターゲットハードウェアリソースのリソース管理方式を示す。サービス層が、リソース管理ポリシーに基づいて、ハードウェア層に含まれるハードウェアリソースの動作ステータスを調整するプロセスは、サービス層が、第1のプロパティによって示されるリソース管理方式に基づいて、識別子によって示されるターゲットハードウェアリソースの動作ステータスを調整することを含みうる。

リソース管理ポリシーでは、異なるハードウェアリソースに対して異なるリソース管理方式が構成されえ、これにより、サービス層は、リソース管理ポリシーに基づいて異なるハードウェアリソースの動作ステータスに対して目的の調整を行うことができる。

任意選択で、リソース管理ポリシーは、第2のプロパティをさらに含んでもよい。第2のプロパティは、ターゲットハードウェアリソースを管理するための起動条件を示す。サービス層が、第1のプロパティによって示されるリソース管理方式に基づいて、識別子によって示されるターゲットハードウェアリソースの動作ステータスを調整するプロセスは、識別子によって示されるターゲットハードウェアリソースの動作ステータスが第2のプロパティによって示される起動条件を満たすとサービス層が決定した場合に、サービス層が、第1のプロパティによって示されるリソース管理方式に基づいてターゲットハードウェアリソースの動作ステータスを調整することを含みうる。

言い換えれば、サービス層は、ターゲットハードウェアリソースの動作ステータスが起動条件を満たすと決定した後に、ターゲットハードウェアリソースの動作ステータスを調整しうる。サービス層が、ターゲットハードウェアリソースの動作ステータスが起動条件を満たさないと決定した場合、サービス層は、ターゲットハードウェアリソースの動作ステータスを調整する必要がない。このようにして、ハードウェアリソースの動作ステータスを誤って調整することによって組み込みデバイスの性能が影響を受けることが防止されることができ、リソーススケジューリングの信頼性が保証される。

任意選択で、リソース管理方式は、ターゲットハードウェアリソースを無効化すること、またはターゲットハードウェアリソースの動作周波数を低減することを含む。

サービス層は、ターゲットハードウェアリソースを無効化するか、またはターゲットハードウェアリソースの動作周波数を低減することによって、組み込みデバイスの電力消費を効果的に低減することができる。

任意選択で、サービス層が、リソース管理ポリシーに基づいて、ハードウェア層に含まれるハードウェアリソースの動作ステータスを調整するプロセスは、サービス層が、組み込みデバイスで状態切り替えが発生し、状態切り替えがハードウェアリソース調整条件を満たすことを検出した場合に、サービス層が、リソース管理ポリシーに基づいてハードウェアリソースの動作ステータスを調整することを含んでもよい。

調整条件は、サービス層で事前構成されてもよいし、または構成ファイルで運ばれてもよい。状態切り替えが調整条件を満たすときにハードウェアリソースの動作ステータスが調整され、これにより、ハードウェアリソースの動作ステータスの頻繁な調整によって引き起こされる組み込みデバイスの不安定な状態が回避されることができる。

任意選択で、サービス層がハードウェア層のハードウェアリソースパラメータを取得するプロセスは、サービス層が、AUTOSAR開発ツールによって送信された構成コマンドを受信し、サービス層が、構成コマンドに従ってハードウェア層のハードウェアリソースパラメータを取得することを含んでもよい。

任意選択で、ハードウェアリソースパラメータは、マシンパラメータおよびシステムパラメータを含んでもよい。マシンパラメータは、プロセッサの関連パラメータ、メモリの関連パラメータ、およびハードディスクの関連パラメータを少なくとも含んでもよい。システムパラメータは、ネットワークパラメータを含んでもよく、例えば、ネットワークアダプタの関連パラメータを含んでもよい。

他の態様によれば、組み込みデバイスが提供される。組み込みデバイスは、AUTOSARを使用し、組み込みデバイスは、ハードウェア層、サービス層、およびアプリケーション層を含む。サービス層は、通信インターフェースおよび少なくとも1つのモジュールを含みうる。通信インターフェースおよび少なくとも1つのモジュールは、前述の態様で提供されるパラメータ構成方法を実施するように構成されうる。

さらに他の態様によれば、組み込みデバイスが提供される。組み込みデバイスはAUTOSARを使用し、組み込みデバイスはメモリおよびプロセッサを含む。メモリは、コンピュータプログラムを記憶するように構成される。プロセッサは、メモリに記憶されたコンピュータプログラムを実行し、これにより、組み込みデバイスは、前述の態様で提供されるパラメータ構成方法を行うように構成される。

さらに他の態様によれば、パラメータ構成システムが提供される。システムは、AUTOSAR開発ツールと、前述の態様による組み込みデバイスとを含む。AUTOSAR開発ツールは、組み込みデバイスのサービス層によって送信されたハードウェアリソースパラメータに基づいて、実行可能ファイルおよび構成ファイルを生成するように構成される。

さらにまた他の態様によれば、コンピュータ可読記憶媒体が提供される。コンピュータ可読記憶媒体は命令を記憶し、命令は、前述の態様で提供されるパラメータ構成方法を実施するためにプロセッサによって実行される。

さらなる態様によれば、命令を含むコンピュータプログラム製品が提供される。コンピュータプログラム製品がコンピュータ上で動作するとき、コンピュータは、前述の態様で提供されるパラメータ構成方法を行うことが可能である。

さらにさらなる態様によれば、チップが提供される。チップは、プログラマブル論理回路および／またはプログラム命令を含み、動作するときに、チップは、前述の態様で提供されるパラメータ構成方法を実施するように構成される。

本出願で提供される技術的解決策は、少なくとも以下の有益な効果を含む。

本出願は、パラメータ構成方法、装置、およびシステムを提供する。組み込みデバイスのサービス層は、ハードウェア層のハードウェアリソースパラメータを直接取得し、ハードウェアリソースパラメータをAUTOSAR開発ツールに送信しえ、これにより、AUTOSAR開発ツールは、構成ファイルおよび実行可能ファイルを生成する。開発者は、開発ツールにハードウェアリソースパラメータを手動で入力する必要がない。したがって、パラメータ構成効率が効果的に改善されることができ、誤ったパラメータ構成の確率が低減されることができ、アプリケーション開発効率がさらに改善されることができる。

本出願の一実施形態によるAUTOSAR APのアーキテクチャ図である。 本出願の一実施形態によるパラメータ構成方法の適用シナリオの概略図である。 本出願の一実施形態によるパラメータ構成方法のフローチャートである。 本出願の一実施形態による、サービス層のターゲットサービスモジュールの構造の概略図である。 本出願の一実施形態による構成ツールの構成インターフェースの概略図である。 本出願の一実施形態による他の構成ツールの構成インターフェースの概略図である。 本出願の一実施形態によるハードウェアリソースの動作ステータスを調整するための方法のフローチャートである。 本出願の一実施形態による他のパラメータ構成方法のフローチャートである。 本出願の一実施形態による他のパラメータ構成方法のフローチャートである。 本出願の一実施形態によるサーバ層の構造の概略図である。 本出願の一実施形態による組み込みデバイスの構造の概略図である。

添付の図面を参照して、以下は、本出願の実施形態で提供されるパラメータ構成方法、装置、およびシステムを詳細に説明する。

AUTOSAR階層ソフトウェアアーキテクチャの基本ソフトウェア（basic software、BSW）層は、異なる製造業者によって生産される車両および異なる供給業者によって提供される電子構成要素に適用されることができる。これは、研究開発費を低減し、ますます複雑化する自動車の電気およびソフトウェアアーキテクチャに適応することができる。AUTOSARは、2つの主要なタイプのプラットフォームを含む。

1．AUTOSARクラシックプラットフォーム（classic platform、CP）：AUTOSAR CPは、自動車エレクトロニクスのためのオープンシステムおよび対応インターフェース（open systems and the corresponding interfaces for automotive electronics、OSEK）規格に基づく組み込みリアルタイム電子制御ユニット（electronic control unit、ECU）規格である。AUTOSAR CPのアーキテクチャは、マイクロコントローラ上で動作するアプリケーション層、ランタイム環境（runtime environment、RTE）層、およびBSW層を含む。アプリケーション層は、基本的にハードウェアから独立している。アプリケーション層のソフトウェア構成要素は、RTE層を用いて互いに通信し、ソフトウェア構成要素はまた、RTEを用いてBSWにアクセスする必要がある。

2．AUTOSAR適応プラットフォーム（adaptive platform、AP）：AUTOSAR APは、2つのタイプのインターフェース：サービスインターフェースおよびアプリケーションプログラミングインターフェース（application programming interface、API）を使用することができる。AUTOSAR APは、サービス層およびAUTOSAR APベース（AUTOSAR AP base）で分散された機能クラスタからなる。

図1は、本出願の一実施形態によるAUTOSAR APのアーキテクチャ図である。図1に示されているように、AUTOSAR APのアーキテクチャは、ハードウェア（hardware）層01、オペレーティングシステム（operating system、OS）インターフェース（interface）02、サービス層03、およびアプリケーション層04を含みうる。OSインターフェース02は、ポータブルオペレーティングシステムインターフェース（portable operating system interface、POSIX）であってもよい。サービス層03は、複数のミドルウェア（middleware）を含みえ、ミドルウェアは、サービスモジュールとも呼ばれうる。

例えば、図1を参照されたい。サービス層03は、以下のサービスモジュール：通信管理（communication management、CM）モジュール、コアタイプ（core type）モジュール、RESTfulモジュール、永続性（persistency）モジュール、実行管理（execution management、EM）モジュール、時間同期（time synchronization）モジュール、プラットフォーム健全性管理（platform health management、PHM）モジュール、アイデンティティおよびアクセス管理（identity and access management、IAM）モジュール、診断（diagnostics）モジュール、ログおよび追跡（log and trace）モジュール、暗号（cryptograph）モジュール、状態管理（state management、SM）モジュール、ネットワーク管理（network management、NM）モジュール、ならびに更新および構成管理（update and configuration management）モジュールなどを含みうる。RESTfulは、表現状態転送（representational state transfer、REST）に基づく開発方式である。

自動車インテリジェンスおよび電化の出現により、自動車の電子計算能力はますます高くなり、メモリはますます大きくなり、電子および電気構造はますます複雑になっている。結果として、AUTOSAR構成項目は規模が大きく、構造が複雑であり、学習閾値が高い。例えば、デバイスのハードウェア構造がますます複雑になるにつれて、ユーザによって手動で入力される必要があるハードウェアリソースパラメータが増加する。結果として、パラメータ構成プロセスはエラーを起こしやすく、構成効率は低い。

本出願の一実施形態は、ハードウェアリソースパラメータを構成する際の低効率の問題を解決するために、パラメータ構成方法を提供する。図2は、本出願の一実施形態によるパラメータ構成方法の適用シナリオの概略図である。図2に示されているように、適用シナリオは、AUTOSARを用いる組み込みデバイス001と、AUTOSAR開発ツール002とを含みうる。AUTOSAR開発ツール002は、構成ツール0021および生成ツール0022を含みうる。構成ツール0021は、取得された構成パラメータ（ハードウェアリソースパラメータおよび機能構成パラメータを含む）に基づいて記述ファイルを生成するように構成される。生成ツール0022は、記述ファイルに基づいて構成ファイルおよび実行可能（executable、exe）ファイルを生成するように構成される。例えば、生成ツール0022は、記述ファイルに基づいてコードファイルを生成し、次にコードファイルをコンパイルして実行可能ファイルを取得しうる。

記述ファイルは、AUTOSAR拡張可能マークアップ言語（AUTOSAR extensible markup language、arxml）フォーマットのファイルであってもよい。構成ファイルは、JavaScript（スクリプト言語）オブジェクト表記（JavaScript object notation、JSON）フォーマットのファイルであってもよい。

図3は、本出願の一実施形態によるパラメータ構成方法のフローチャートである。本方法は、図2に示されている適用シナリオに適用されうる。例えば、図2に示されている組み込みデバイス002は、AUTOSAR APを使用しうる。図1に示されているように、組み込みデバイス002は、ハードウェア層01、サービス層03、およびアプリケーション層04を含みうる。図2を参照されたい。本方法は、以下のステップを含む。

ステップ101：構成ツールは構成命令をサービス層に送信する。

本出願のこの実施形態では、構成ツールが、記述ファイルを生成するために組み込みデバイスのハードウェア層のハードウェアリソースパラメータを取得する必要があるとき、構成ツールは構成命令をサービス層に送信しうる。構成命令は、ハードウェア層のハードウェアリソースパラメータを取得するようにサービス層に命令するために使用される。

任意選択で、組み込みデバイスのサービス層に含まれる複数のサービスモジュール内に1つのターゲットサービスモジュールがあってもよい。ターゲットサービスモジュールは、構成ツールと通信することができ、ハードウェア層に含まれるハードウェアリソースをスケジュールおよび管理することができる。ターゲットサービスモジュールは、サービス層のEMモジュール、SMモジュール、CMモジュール、またはPHMモジュールなどであってもよい。

図4は、本出願の一実施形態による、サービス層のターゲットサービスモジュールの構造の概略図である。図4に示されているように、ターゲットサービスモジュールは、通信インターフェース031およびリソース管理モジュール032を含みうる。通信インターフェース031は、構成ツールと通信するように構成される。これに対応して、構成ツールは、サービス層のターゲットサービスモジュールの通信インターフェース031に構成命令を送信しうる。リソース管理モジュール032は、解析サブモジュール032aおよび管理サブモジュール032bを含む。解析サブモジュール032aは、ハードウェア層のハードウェアリソースパラメータを解析および取得するように構成され、管理サブモジュール032bは、ハードウェア層に含まれるハードウェアリソースをスケジュールおよび管理するように構成される。

通信インターフェース031は、伝送制御プロトコル（transmission control protocol、TCP）、ハイパーテキスト転送プロトコル（hypertext transfer protocol、HTTP）、またはリモートプロシージャコール（remote procedure call、RPC）などのプロトコルに基づいて開発されたインターフェースであってもよい。

ステップ102：サービス層は、構成命令に従ってハードウェア層のハードウェアリソースパラメータを取得する。

構成命令を受信した後、組み込みデバイスのサービス層は、構成命令に応答してハードウェア層のハードウェアリソースパラメータを取得しうる。本出願のこの実施形態では、ハードウェアリソースパラメータは、マシン（machine）パラメータおよびシステム（system）パラメータを含みうる。machineパラメータは、プロセッサ（processor）の関連パラメータ、メモリの関連パラメータ、およびハードディスクの関連パラメータを少なくとも含みうる。systemパラメータは、ネットワークパラメータを含んでもよく、例えば、ネットワークアダプタの関連パラメータを含んでもよい。プロセッサは、中央処理装置（central processing unit、CPU）などを含みえ、プロセッサは、複数のプロセッサコア（cores）を含みうる。

任意選択で、マシンパラメータおよびシステムパラメータに加えて、ハードウェアリソースパラメータは、他のタイプのパラメータをさらに含んでもよく、他のタイプのパラメータは、電子制御ユニット（electronic control unit、ECU）の関連パラメータ、マイクロコントローラユニット（microcontroller unit、MCU）の関連パラメータ、および周辺機器（例えば、カメラ、レーザレーダなどのセンサ）の関連パラメータなどを含んでもよい。

図4を参照されたい。構成命令を受信した後、サービス層のターゲットサービスモジュールの通信インターフェース031は、構成命令をリソース管理モジュール032に送信しうる。リソース管理モジュール032内の解析サブモジュール032aは、構成命令に応答してハードウェア層のハードウェアリソースパラメータをさらに取得しうる。

ステップ103：サービス層は、ハードウェアリソースパラメータを構成ツールに送信する。

ハードウェアリソースパラメータを取得した後、サービス層は、AUTOSAR開発ツール内の構成ツールにハードウェアリソースパラメータを送信しうる。ハードウェアリソースパラメータは、記述ファイルを生成するために構成ツールによって使用され、開発ツール内の生成ツールは、記述ファイルに基づいて実行可能ファイルおよび構成ファイルをさらに生成しうる。

例えば、図4を参照されたい。サービス層のターゲットサービスモジュールは、通信インターフェース031を介して、取得されたハードウェアリソースパラメータを構成ツールに送信しうる。

図5は、本出願の一実施形態による構成ツールの構成インターフェースの概略図である。図5に示されているように、サービス層によって送信され、構成ツールによって受信されるマシンパラメータは、CPUの関連パラメータを含みえ、CPUの関連パラメータは、CPU内の各coreのパラメータを含みうる。例えば、図5を参照されたい。CPUの関連パラメータは、CPU0内のcore0からcore3のパラメータ、およびCPU1内のcore0およびcore1のパラメータを含みうる。各coreアのパラメータは、以下のプロパティ：カテゴリ（category）、チェックサム（checksum）、コアID（core ID）、ショートネーム（short name）、タイムスタンプ（timestamp）、および汎用一意識別子（universally unique identifier、UUID）を含みうる。

図6は、本出願の一実施形態による他の構成ツールの構成インターフェースの概略図である。図6に示されているように、サービス層によって送信され、構成ツールによって受信されるシステムパラメータは、イーサネットの関連パラメータを含みうる。図6を参照されたい。イーサネットの関連パラメータは、以下のプロパティ（property）：ボーレート（baud rate）、チェックサム、カップリングポートスイッチオフ遅延（coupling port switchoff delay）、プロトコル名（protocol name）、プロトコルバージョン（protocol version）、速度（speed）、およびタイムスタンプ（timestamp）のうちの少なくとも1つを含みうる。

イーサネットの関連パラメータは、インターネットプロトコルバージョン4（Internet protocol version 4、IPv4）構成パラメータをさらに含みえ、IPv4構成パラメータは、以下のプロパティ：割り当て優先度（assignment priority）、チェックサム、デフォルトゲートウェイ（default gateway）、ドメイン名システム（domain name system、DNS）サーバアドレス（server address）、IPアドレス保持挙動（IP address keep behavior）、IPv4アドレス（IPv4 address）、IPv4アドレスソース（IPv4 address source）、ネットワークマスク（network mask）、タイムスタンプ、および生存時間（time－to－live、TTL）値のうちの少なくとも1つを含みうる。プロパティ：IPアドレス保持挙動の値（value）は、永続的に記憶する（store persistently）であり、プロパティ：IPv4アドレスソースの値は、IPv4ホストによって必要とされるIPアドレスを構成するために使用される動的ホスト構成プロトコル（dynamic host configuration protocol、DHCP）を表すDHCPV－4である。

ステップ104：構成ツールは、ハードウェアリソースパラメータに基づいて記述ファイルを生成する。

本出願のこの実施形態では、AUTOSARメタモデルが構成ツールにおいて事前構成される。サーバ層によって送信されたハードウェアリソースパラメータを受信した後、構成ツールは、ハードウェアリソースパラメータおよびメタモデルに基づいてAUTOSARモデルを生成しうる。このプロセスは、AUTOSARモデルへのハードウェアリソースパラメータのマッピングとも呼ばれうる。次に、記述ファイルを取得するために、構成ツールのメモリから構成ツールのハードディスクにAUTOSARモデルがエクスポートされる。記述ファイルは、．arxmlフォーマットのファイルであってもよい。

AUTOSARメタモデルは、AUTOSARシステムを記述するための言語を定義するための統一モデリング言語（unified modeling language、UML）モデルであり、テンプレートのグラフィカル表現である（テンプレートは、AUTOSARハードウェアおよびソフトウェアシステムを形成するためのソフトウェア構成要素およびECUなどの構造を定義する）。AUTOSARモデルは、AUTOSARモデルのインスタンスある。

ステップ105：生成ツールは、記述ファイルに基づいて実行可能ファイルおよび構成ファイルを生成する。

構成ツールが記述ファイルを生成した後、生成ツールは、記述ファイルを取得し、記述ファイルに基づいて実行可能ファイルおよび構成ファイルを生成しうる。実行可能ファイルは．exeフォーマットのファイルであってもよく、構成ファイルは．jasonフォーマットのファイルであってもよい。本出願のこの実施形態では、開発者は、生成ツールによって生成された実行可能ファイルおよび構成ファイルの両方を組み込みデバイスのハードウェア層にさらに記憶しうる。

ステップ106：サービス層は、構成ファイルに基づいて実行可能ファイルを動作させる。

本出願のこの実施形態では、サービス層は、ハードウェア層で構成ファイルを読み出し、構成ファイルに基づいて実行可能ファイルを動作させうる。

ステップ107：サービス層は、構成ファイル内のリソース管理ポリシーに基づいて、ハードウェア層に含まれるハードウェアリソースの動作ステータスを調整する。

構成ファイルは、リソース管理ポリシーを含みうる。サービス層は、組み込みデバイスの動作プロセスにおいてリソース管理ポリシーに基づいて、ハードウェア層に含まれるハードウェアリソースの動作ステータスを調整しうる。このようにして、ハードウェアリソースは柔軟にスケジュールおよび管理されことができ、組み込みデバイスの適切な動作に影響を及ぼすことなく、組み込みデバイスの電力消費が効果的に低減されることができる。

任意選択で、構成ファイル内のリソース管理ポリシーは、少なくとも1つのポリシー構成項目を含んでもよく、各ポリシー構成項目は、ハードウェア層のハードウェアリソースの管理ポリシーを示すために使用される。ハードウェア層のターゲットハードウェアリソースが、例として使用される。ターゲットハードウェアリソースのポリシー構成項目は、ターゲットハードウェアリソースの識別子および第1のプロパティを含みうる。第1のプロパティは、ターゲットハードウェアリソースのリソース管理方式を示し、リソース管理方式は、ターゲットハードウェアリソースを無効にすること、またはターゲットハードウェアリソースの動作周波数を低減することを含みうる。

例えば、ターゲットハードウェアリソースがプロセッサコアである場合、ターゲットハードウェアリソースの識別子は、プロセッサコアの識別子（identifier、ID）と、プロセッサコアが属するプロセッサのIDとを含みうる。ターゲットハードウェアリソースがセンサである場合、ターゲットハードウェアリソースの識別子は、センサのIDでありうる。

リソース管理ポリシーでは、サービス層がリソース管理ポリシーに基づいて異なるハードウェアリソースの動作ステータスに対して目的の調整を行うことができるように、異なるハードウェアリソースに対して異なるリソース管理方式が構成されうることが理解されうる。

本出願のこの実施形態では、ターゲットハードウェアリソースのポリシー構成項目は、第2のプロパティをさらに含みえ、第2のプロパティは、ターゲットハードウェアリソースを管理するための起動条件を示す。言い換えれば、サービス層は、ターゲットハードウェアリソースの動作ステータスが起動条件を満たすと決定した後に、ターゲットハードウェアリソースの動作ステータスを調整しうる。このようにして、リソースの動作ステータスを誤って調整することによって組み込みデバイスの性能が影響を受けることが防止されることができ、リソーススケジューリングの信頼性が保証される。

ステップ107の実施プロセスは、ターゲットハードウェアリソースのポリシー構成項目が、ターゲットハードウェアリソースの識別子、第1のプロパティ、および第2のプロパティを含む例を使用して説明される。図7を参照されたい。ステップ107は、以下のステップを含みうる。

ステップ1071：組み込みデバイスで状態切り替えが発生したことを検出したとき、サービス層は、状態切り替えがハードウェアリソース調整条件を満たすかどうか決定する。

本出願のこの実施形態では、サービス層は、組み込みデバイスの動作プロセスにおいて、組み込みデバイスのステータス（マシンのステータスとも呼ばれうる）をリアルタイムで監視しうる。組み込みデバイスの状態が変化したことを検出したとき、すなわち、組み込みデバイスの状態が切り替えられたとき、サービス層は、状態切り替えがハードウェアリソース調整条件を満たすかどうかをさらに検出しうる。サービス層が、状態切り替えがハードウェアリソース調整条件を満たすと決定した場合、ステップ1072が行われうる。サービス層が、状態切り替えがハードウェアリソース調整条件を満たさないと決定した場合、サービス層は動作を終了しうる、すなわち、ハードウェアリソースの動作ステータスを調整しない。加えて、サービス層は、組み込みデバイスのステータスを引き続き監視しうる。

調整条件は、サービス層で事前構成されてもよいし、または構成ファイルで運ばれてもよい。例えば、調整条件は、以下の条件：状態切り替えの前後で、ハードウェアリソース使用率（例えば、CPU使用率）の変化量が変化量閾値よりも大きいこと、状態切り替え後に、ハードウェアリソース使用率が使用率閾値未満であること、状態切り替え後に、一部のプロセスがゾンビ状態にあること、および状態切り替え後に、組み込みデバイスによって実行されるタスクが、性能消費が消費閾値よりも小さいタスクであることのうちの1つ以上を含みうる。

本出願のこの実施形態で提供される方法によれば、状態切り替えが調整条件を満たすときにハードウェアリソースの動作ステータスが調整されえ、これにより、ハードウェアリソースの動作ステータスの頻繁な調整によって引き起こされる組み込みデバイスの不安定な状態が回避されることができる。

ステップ1072：サービス層は、ハードウェア層のターゲットハードウェアリソースの動作ステータスが第2のプロパティによって示される起動条件を満たすかどうかを検出する。

組み込みデバイスの状態切り替えがハードウェアリソース調整条件を満たすことを検出したとき、サービス層は、構成ファイル内のリソース管理ポリシーに基づいて、ハードウェア層に含まれるハードウェアリソースの動作ステータスを調整しうるリソース管理ポリシーがターゲットハードウェアリソースのポリシー構成項目を含む場合、サービス層は、ポリシー構成項目内の識別子に基づいてハードウェア層のターゲットハードウェアリソースを決定し、ターゲットハードウェアリソースが第2のプロパティによって示される起動条件を満たすかどうかを検出しうる。

サービス層が、ターゲットハードウェアリソースの動作ステータスが第2のプロパティによって示される起動条件を満たすと決定した場合、サービス層は、ステップ1073を引き続き行いうる。サービス層が、ターゲットハードウェアリソースの動作ステータスが第2のプロパティによって示される起動条件を満たさないと決定した場合、サービス層は動作を終了しうる、すなわち、ターゲットハードウェアリソースの動作ステータスを調整しない。このようにして、ハードウェアリソースの動作ステータスを誤って調整することによって組み込みデバイスの性能が影響を受けることが防止されることができ、リソーススケジューリングの信頼性が保証される。

ステップ1073：サービス層は、第1のプロパティによって示されるリソース管理方式に基づいてターゲットハードウェアリソースの動作ステータスを調整する。

サービス層が、ターゲットハードウェアリソースの動作ステータスが第2のプロパティによって示される起動条件を満たすと決定した場合、サービス層は、第1のプロパティによって示されるリソース管理方式に基づいてターゲットハードウェアリソースの動作ステータスを調整しうる。

例えば、ターゲットハードウェアリソースがハードウェア層のプロセッサコアであり、プロセッサコアのリソース構成項目内の第1のプロパティによって示されるリソース管理方式が、プロセッサコアを無効にすることであり、第2のプロパティによって示される起動条件が、プロセッサコアの使用率が10％未満であると仮定される。この場合、サービス層は、プロセッサコアの使用率が10％未満であることを検出したときにプロセッサコアを無効にしうる。

ハードウェア層は複数のハードウェアリソースを含みえ、例えば、プロセッサ、メモリ、ネットワークアダプタ、ECU、MCU、および周辺機器などを含みえ、プロセッサは複数の異なるプロセッサコアをさらに含みうることを理解されたい。したがって、リソース管理ポリシーは、複数の異なるハードウェアリソースのポリシー構成項目を含みうる。これに対応して、サービス層は、ハードウェア層のハードウェアリソースの柔軟なスケジューリングを実施するために、各ポリシー構成項目に基づいて、対応するハードウェアリソースの動作ステータスを調整しうる。

本出願のこの実施形態では、ハードウェア層の少なくとも1つのタイプのハードウェアリソース（例えば、プロセッサ、メモリ、ネットワークアダプタ、ECU、MCU、および周辺機器など）に関して、ハードウェアリソースを管理するためのポリシー構成（strategy config）項目が、構成ツールに記憶されるメタモデルに追加されうる。構成ツールがメタモデルに基づいて構成ファイルを生成した後、構成ファイルはハードウェアリソースのポリシー構成項目を含みうる。

例えば、ハードウェア層のプロセッサはCPUである。CPU内のプロセッサコアに関して、メタモデルに追加される新しいポリシー構成項目は表1に示されえ、ポリシー構成項目のベース（base）タイプはAUTOSARオブジェクト（AR object）タイプである。表1を参照されたい。ポリシー構成項目は複数のプロパティ（attribute、attr）を含むことが知られることができる

プロパティ名がShortnameであるプロパティのタイプ（type）は文字列（String）でありえ、プロパティの構成可能な数は1であり、プロパティはポリシー構成項目の名称を識別するために使用されうる。例えば、CPUのポリシー構成項目の名称は、CPU Strategy Configであってもよい。

プロパティ名がCpuIdであるプロパティのタイプは、非負整数（non－negative integer）でありえ、構成可能なプロパティの数は1であり、プロパティは、プロセッサコアが属するプロセッサ（machineパラメータ内のprocessorに対応する）を識別するために使用されえ、プロパティの値の範囲は、0以上でありうる。

プロパティ名がCoreIdであるプロパティのタイプは、非負整数でありえ、構成可能なプロパティの数は1であり、プロパティは、プロセッサコア（machineパラメータ内のProcessor Coreに対応する）を識別するために使用されえ、プロパティの値の範囲は、0以上でありうる。

プロパティ名がMethod（モード）であるプロパティのタイプは、列挙（enum）タイプでありえ、構成可能なプロパティの数は1であり、プロパティは、リソース管理方式を示すために使用されえ、プロパティの値は、動作周波数の低減（reduce）または終了（close）でありうる。

プロパティ名がThreshold（閾値）であるプロパティのタイプは非負整数でありえ、構成可能なプロパティの数は0または1であり、プロパティは、リソース管理が開始されたときに使用率が到達する必要があるより低い閾値を示すために使用されえ、プロパティの値の範囲は［0，100］でありうる。すなわち、プロセッサコアの使用率が、プロパティ名がThresholdであるプロパティの値よりも大きいとき、サービス層は、プロパティ名がMethodであるプロパティによって示されるリソース管理方式に基づいてプロセッサコアの動作ステータスを調整しうる。

表1の構成可能なプロパティの数は、ポリシー構成項目がプロパティを含む必要があるかどうかを示す。構成可能なプロパティの数が1である場合、ポリシー構成項目はプロパティを含む必要がある。構成可能なプロパティの数が0または1である場合、ポリシー構成項目はプロパティを含んでもよいし、またはプロパティを含まなくてもよい。例えば、プロパティ名がThresholdであるプロパティは、表1に示されているプロセッサコアのポリシー構成項目に含まれなくてもよい。

構成ツールがメタモデルに基づいて構成ファイルを生成した後、構成ファイル内のプロセッサコアのポリシー構成項目において、プロセッサコアの識別子は、プロパティ名がCpuIdであるプロパティの値と、プロパティ名がCoreIdであるプロパティの値とを含むことが理解されうる。第1のプロパティは、プロパティ名がMethodであるプロパティの値であり、第2のプロパティは、プロパティ名がThresholdであるプロパティの値である。ハードウェア層のECUおよびMCUなどのハードウェアリソースのポリシー構成項目については、表1を参照することがさらに理解されうる。

ハードウェア層の周辺機器に関して、メタモデルに追加される新しいポリシー構成項目が表2に示されうる。表2を参照されたい。ポリシー構成項目はまた、複数のプロパティを含みうることが知られることができる。プロパティ名がShortnameであるプロパティのタイプは文字列でありえ、構成可能なプロパティの数は1であり、プロパティは、ポリシー構成項目の名称を識別するために使用されうる。例えば、名称はDevice Power Configでありうる。

プロパティ名がDeviceIDであるプロパティのタイプは、非負整数でありえ、構成可能なプロパティの数は1であり、プロパティは、リソース管理を行う必要がある周辺機器の識別子を識別するために使用されうる。

プロパティ名がMethodであるプロパティのタイプは列挙型でありえ、構成可能なプロパティの数は1であり、プロパティはリソース管理方式を示すために使用されうる。例えば、プロパティの値は、動作周波数の低減または無効化でありうる。

本出願のこの実施形態では、構成ファイルがハードウェアリソースのリソース構成項目を含む場合、ターゲットサービスモジュールは、組み込みデバイスの動作プロセスにおいてデバイスステータスに基づいてハードウェアリソースを管理しうる。例えば、構成ファイルがレーザレーダのリソース構成項目を含み、リソース構成項目においてプロパティ名がMethodであるプロパティの値が無効化であると仮定すると、ターゲットサービスモジュールは、駐車状態においてレーザレーダの電源をオフにしうる。構成ファイルが前面カメラのリソース構成項目を含み、リソース構成項目においてプロパティ名がMethodであるプロパティの値が無効化である場合、ターゲットサービスモジュールは、後進のときに前面カメラの電源をオフにしうる。

本出願のこの実施形態で提供される前述のパラメータ構成方法の一連のステップは適切に調整されてもよいし、またはステップが、状況に基づいて適宜追加または削除されてもよいことがさらに理解されうる。例えば、ステップ101が、状況に基づいて削除されてもよい。代わりに、ステップ1071が、状況に基づいて削除されてもよく、すなわち、状態切り替えが組み込みデバイスで発生したことを検出したとき、サービス層は、状態切り替えが調整条件を満たすかどうかを決定することなく、リソース管理ポリシーに基づいてハードウェアリソースの動作ステータスを直接調整してもよい。代わりに、ステップ1072が、状況に基づいて削除されてもよく、すなわち、ポリシー構成項目は第2のプロパティを含まなくてもよい。これに対応して、サービス層は、ターゲットハードウェアリソースの動作ステータスが起動条件を満たすかどうかを決定する必要はないが、第1のプロパティによって示されるリソース管理方式に基づいてターゲットハードウェアリソースの動作ステータスを直接調整することができる。

以下は、サービス層のEMモジュールがターゲットサービスモジュールである例を使用して、本出願の一実施形態で提供されるパラメータ構成方法を説明する。図8Aおよび図8Bを参照されたい。本方法は、以下のステップを含みうる。

ステップ201：構成ファイルを読み出す。

本出願のこの実施形態では、起動された後、EMモジュールは、最初に、ハードウェア層において記憶された構成ファイルを読み出しうる。次に、EMモジュールは、以下のステップ202、ステップ203、およびステップ204を行いうる。

ステップ202：構成ファイルに基づいてサービス層の他のサービスモジュールを起動し、アプリケーション層のアプリケーションを起動する。

構成ファイル内の構成パラメータに基づいて、EMは、サービス層の他のサービスモジュール（例えば、CMモジュールおよびSMモジュール）を起動し、アプリケーション層のアプリケーションを起動しうる。

ステップ203：命令リスニング機能を有効化する。

EMモジュールは、構成ファイルに基づいて命令リスニング機能を有効化し、ステップ205を行いうる。

ステップ204：ステータスリスニング機能を有効化する。

本出願のこの実施形態では、EMモジュールは、構成ファイルに基づいてステータスリスニング機能をさらに有効化し、ステップ209を行いうる。

ステップ205：命令が受信されたかどうかを検出する。

命令リスニング機能を有効化した後、EMモジュールは、他のデバイス（例えば、構成ツール）によって送信された命令が受信されたかどうかをリアルタイムで検出することができる。EMモジュールが命令を受信した場合、ステップ206が行われうる。EMモジュールが命令を受信していない場合、ステップ205が引き続き行われうる、すなわち、命令が受信されたかどうかを検出する。

ステップ206：命令タイプを解析する。

命令を受信した後、EMモジュールは、命令の命令タイプを決定するために命令を解析しうる。

ステップ207：命令が構成命令である場合、ハードウェアリソースパラメータを取得する。

EMモジュールが、命令が構成ツールによって配信された、ハードウェアリソースパラメータを取得するように命令するために使用される構成命令であると決定した場合、EMモジュールは、構成命令に従って、ハードウェア層に含まれるハードウェアリソースのハードウェアリソースパラメータを取得しうる。

ステップ208：ハードウェアリソースパラメータを構成ツールに送信する。

ハードウェアリソースパラメータを取得した後、EMモジュールは、通信インターフェースを介してハードウェアリソースパラメータを構成ツールに送信しうる。

ステップ209：状態切り替えが発生したかどうかを検出する。

ステップ204において、ステータスリスニング機能を有効化した後、EMモジュールは、組み込みデバイスのステータスをリアルタイムで監視し、組み込みデバイスの状態が切り替えられたかどうかを決定しうる。EMモジュールが、組み込みデバイスの状態が切り替えられたと決定した場合、ステップ210が行われうる。EMモジュールが、組み込みデバイスの状態が切り替えられていないと決定した場合、EMモジュールはステップ209を引き続き行いうる、すなわち、組み込みデバイスのステータスを引き続き監視しうる。

例えば、新しいプロセスが開始されたことまたはプロセスが再開されたことを検出したとき、EMモジュールは、組み込みデバイスで状態切り替えが発生したと決定しうる。

ステップ210：状態切り替えがハードウェアリソース調整条件を満たすかどうかを決定する。

組み込みデバイスの状態が切り替えられたと決定した後、EMモジュールはさらに、状態切り替えがハードウェアリソース調整条件を満たすかどうか、すなわち、状態切り替えがハードウェアリソーススケジューリングに影響を及ぼすどうかを引き続き決定しうる。EMモジュールが、状態切り替えがハードウェアリソース調整条件を満たすと決定した場合、ステップ211が行われうる。EMモジュールが、状態切り替えがハードウェアリソース調整条件を満たさないと決定した場合、ステップ209が引き続き行われうる。ステップ210の実施プロセスについては、ステップ1071を参照されたい。ここでは詳細は再び説明されない。

ステップ211：構成ファイル内のリソース管理ポリシーに基づいて、ハードウェアリソースの動作ステータスが調整される必要があるかどうかを決定する。

EMモジュールが、状態切り替えがハードウェアリソーススケジューリングに影響を及ぼすと決定した場合、EMモジュールは、リソース管理ポリシー内の第2のプロパティに基づいて、ハードウェアリソースの動作ステータスが調整される必要があるかどうかを決定しうる。EMモジュールが、ハードウェアリソースの動作ステータスが調整される必要があると決定した場合、ステップ212が行われうる。EMモジュールが、ハードウェアリソースの動作ステータスが調整される必要がないと決定した場合、ステップ209が引き続き行われうる。ステップ211の実施プロセスについては、ステップ1072を参照されたい。ここでは詳細は再び説明されない。

ステップ212：ハードウェア層に含まれるハードウェアリソースの動作ステータスを調整する。

EMモジュールが、ハードウェアリソースの動作ステータスが調整される必要があると決定した場合、EMモジュールは、リソース管理ポリシー内の第1のプロパティによって示されるリソース管理方式で、ハードウェア層に含まれるハードウェアリソースの動作ステータスを調整しうる。ステップ212の実施プロセスについては、ステップ1073を参照されたい。ここでは詳細は再び説明されない。

例えば、サービス層は、以下の効果を達成するために、構成ファイル内のリソース管理ポリシーに基づいてプロセッサの動作ステータスを調整しうる。

1．プロセッサコアにおいて動作しているプロセス（例えば、自動運転プロセス）がゾンビ状態にあることが検出されたとき、プロセッサコアは無効化されるか、またはプロセッサコアの周波数が低減される。

2．プロセッサコアのCPU使用率が閾値よりも低いか、またはプロセッサコアがタスクを実行していないことが検出されたとき、プロセッサコアは無効化されるか、またはプロセッサコアの周波数が低減される。

3．プロセッサの全体的なCPU使用率が閾値よりも低いことが検出されたとき、一部のプロセッサコアが無効化されるか、または一部のプロセッサコアの周波数が低減される。周波数が無効化または低減されるプロセッサコアは、CPU内の高性能プロセッサコアであってもよい。

4．組み込みデバイスによって現在実行されているタスクのリソース消費が比較的低いことが検出されたとき、例えば、組み込みデバイスがアップグレードタスクもしくは自動駐車タスクを実行していること、または自動運転モードがオンではないことが検出されたとき、一部のプロセッサコアが無効化されうるか、または一部のプロセッサコアの周波数が低減されうる。

前述の例に基づいて、本出願のこの実施形態で提供される方法では、CPUは、組み込みデバイスの動作プロセスにおいて組み込みデバイスのステータスに基づいて柔軟にスケジュールされることができることが知られることができる。言い換えれば、本出願のこの実施形態で提供される方法は、CPUホットプラグを実施することができる。

結論として、本出願のこの実施形態はパラメータ構成方法を提供する。組み込みデバイスのサービス層は、ハードウェア層のハードウェアリソースパラメータを直接取得し、ハードウェアリソースパラメータをAUTOSAR開発ツールに送信しうる。開発者は、開発ツールにハードウェアリソースパラメータを手動で入力する必要がない。したがって、パラメータ構成効率が効果的に改善されることができ、アプリケーション開発効率がさらに改善されることができる。

加えて、サービス層は、構成ファイル内のリソース管理ポリシーに基づいてハードウェアリソースの動作ステータスをさらに調整しうるため、ハードウェアリソースの柔軟なスケジューリングが実施されることができる。これは、組み込みデバイスの適切な動作に影響を及ぼすことなく、組み込みデバイスの電力消費が効果的に低減されることを保証することができる。

本出願の一実施形態は、組み込みデバイスをさらに提供する。組み込みデバイスは、車両に適用されえ、例えば、インテリジェント車両、コネクティッド車両、または新エネルギー車両などに適用されうる。組み込みデバイスは、AUTOSARを使用する、例えば、AUTOSAR APアーキテクチャまたはAUTOSAR CPアーキテクチャを使用しうる。図1に示されているように、組み込みデバイスは、ハードウェア層01、サービス層03、およびアプリケーション層04を含みうる。図4および図9に示されているように、サービス層03は、
ハードウェア層のハードウェアリソースパラメータを取得するように構成されたリソース管理モジュール032（リソース管理モジュール032の機能の実施については、前述の方法の実施形態のステップ102およびステップ207の関連説明を参照されたい）と、
ハードウェアリソースパラメータをAUTOSAR開発ツールに送信し、ハードウェアリソースパラメータは、実行可能ファイルおよび構成ファイルを生成するためにAUTOSAR開発ツールによって使用され、実行可能ファイルおよび構成ファイルは、組み込みデバイスのハードウェア層において記憶されうる、ように構成された通信インターフェース031（通信インターフェース031の機能の実施については、前述の方法の実施形態のステップ103およびステップ208の関連説明を参照されたい）と、
構成ファイルに基づいて実行可能ファイルを動作させるように構成された動作モジュール033（動作モジュール033の機能の実施については、前述の方法の実施形態のステップ106の関連説明を参照されたい）と
を含む。

任意選択で、構成ファイルはリソース管理ポリシーを含む。リソース管理モジュール032は、リソース管理ポリシーに基づいて、ハードウェア層に含まれるハードウェアリソースの動作ステータスを調整するようにさらに構成されうる。リソース管理モジュール032の機能の実施については、前述の方法の実施形態のステップ107およびステップ212の関連説明を参照されたい。

任意選択で、リソース管理ポリシーは、ターゲットハードウェアリソースの識別子および第1のプロパティを含み、第1のプロパティは、ターゲットハードウェアリソースのリソース管理方式を示す。リソース管理モジュール032は、第1のプロパティによって示されるリソース管理方式に基づいて、識別子によって示されるターゲットハードウェアリソースの動作ステータスを調整するように構成されうる。

リソース管理モジュール032の機能の実施については、前述の方法の実施形態のステップ1073の関連説明を参照されたい。

任意選択で、リソース管理ポリシーは、第2のプロパティをさらに含む。第2のプロパティは、ターゲットハードウェアリソースを管理するための起動条件を示す。リソース管理モジュール032は、識別子によって示されるターゲットハードウェアリソースの動作ステータスが第2のプロパティによって示される起動条件を満たすとリソース管理モジュールが決定した場合に、第1のプロパティによって示されるリソース管理方式に基づいてターゲットハードウェアリソースの動作ステータスを調整するように構成されうる。

リソース管理モジュール032の機能の実施については、前述の方法の実施形態のステップ1072の関連説明を参照されたい。

任意選択で、リソース管理方式は、ターゲットハードウェアリソースを無効化すること、またはターゲットハードウェアリソースの動作周波数を低減することを含む。

任意選択で、リソース管理モジュール032は、リソース管理モジュールが、組み込みデバイスで状態切り替えが発生し、状態切り替えがハードウェアリソース調整条件を満たすことを検出した場合、リソース管理ポリシーに基づいてハードウェアリソースの動作ステータスを調整するように構成されてもよい。

リソース管理モジュール032の機能の実施については、前述の方法の実施形態のステップ1071、ステップ209、およびステップ210の関連説明を参照されたい。

任意選択で、リソース管理モジュール032は、AUTOSAR開発ツールによって送信された構成コマンドを受信し、構成コマンドに従ってハードウェア層のハードウェアリソースパラメータを取得するように構成される。リソース管理モジュール032の機能の実施については、前述の方法の実施形態のステップ102、およびステップ205からステップ207の関連説明を参照されたい。

任意選択で、リソース管理モジュール032によって取得されるハードウェアリソースパラメータは、マシンパラメータおよびシステムパラメータを含んでもよい。

結論として、本出願のこの実施形態は、組み込みデバイスを提供する。組み込みデバイスのサービス層は、ハードウェア層のハードウェアリソースパラメータを直接取得し、ハードウェアリソースパラメータをAUTOSAR開発ツールに送信しうる。開発者は、開発ツールにハードウェアリソースパラメータを手動で入力する必要がない。したがって、パラメータ構成効率が効果的に改善されることができ、アプリケーション開発効率がさらに改善されることができる。

加えて、サービス層は、構成ファイル内のリソース管理ポリシーに基づいてハードウェアリソースの動作ステータスをさらに調整しうるため、ハードウェアリソースの柔軟なスケジューリングが実施されることができる。これは、組み込みデバイスの適切な動作に影響を及ぼすことなく、組み込みデバイスの電力消費が効果的に低減されることを保証することができる。

簡便な説明のために、組み込みデバイスおよびモジュールの詳細な動作プロセスについては、前述の方法の実施形態における対応するプロセスを参照することが当業者によって明確に理解されうる。ここでは詳細は再び説明されない。

本出願のこの実施形態で提供される組み込みデバイスは、特定用途向け集積回路（application－specific integrated circuit、ASIC）またはプログラマブル論理デバイス（programmable logic device、PLD）を使用して実施されてもよいことを理解されたい。PLDは、複合プログラマブル論理デバイス（complex programmable logic device、CPLD）、フィールドプログラマブルゲートアレイ（field－programmable gate array、FPGA）、汎用アレイ論理（generic array logic、GAL）、またはこれらの任意の組み合わせであってもよい。代わりに、前述の方法の実施形態で提供されるパラメータ構成方法は、ソフトウェアを使用して実施されてもよい。前述の方法の実施形態で提供されるパラメータ構成方法がソフトウェアを使用して実施されるとき、組み込みデバイス内のモジュールは、代わりにソフトウェアモジュールであってもよい。

図10は、本出願の一実施形態による組み込みデバイスの構造の概略図である。図10に示されているように、組み込みデバイスは、プロセッサ1001と、メモリ1002と、ネットワークインターフェース1003と、バス1004とを含みうる。バス1004は、プロセッサ1001、メモリ1002、およびネットワークインターフェース1003を接続するように構成される。他のデバイスへの通信接続は、ネットワークインターフェース1003（有線またはワイヤレスでありうる）を使用して実施されうる。メモリ1002は、コンピュータプログラム10021を記憶し、コンピュータプログラム10021は、様々なアプリケーション機能を実施するために使用される。

本出願のこの実施形態では、プロセッサ1001はCPUであってもよいし、またはプロセッサ1001は、他の汎用プロセッサ、デジタル信号プロセッサ（DSP）、特定用途向け集積回路（ASIC）、フィールドプログラマブルゲートアレイ（FPGA）、GPU、もしくは他のプログラマブル論理デバイス、ディスクリートゲートもしくはトランジスタ論理デバイス、またはディスクリートハードウェア構成要素などであってもよいことを理解されたい。汎用プロセッサは、マイクロプロセッサまたは任意の従来のプロセッサなどであってもよい。

メモリ1002は、揮発性メモリもしくは不揮発性メモリであってもよいし、または揮発性メモリおよび不揮発性メモリの両方を含んでもよい。不揮発性メモリは、読み出し専用メモリ（read－only memory、ROM）、プログラマブル読み出し専用メモリ（programmable ROM、PROM）、消去可能プログラマブル読み出し専用メモリ（erasable PROM、EPROM）、電気的消去可能プログラマブル読み出し専用メモリ（electrically EPROM、EEPROM）、またはフラッシュメモリであってもよい。揮発性メモリは、外部キャッシュとして使用されるランダムアクセスメモリ（random access memory、RAM）であってもよい。限定的な説明ではなく例として、多くの形態のRAM、例えば、スタティックランダムアクセスメモリ（static RAM、SRAM）、ダイナミックランダムアクセスメモリ（DRAM）、シンクロナス・ダイナミック・ランダム・アクセス・メモリ（synchronous DRAM、SDRAM）、ダブル・データ・レート・シンクロナス・ダイナミック・ランダム・アクセス・メモリ（double data rate SDRAM、DDR SDRAM）、拡張シンクロナス・ダイナミック・ランダム・アクセス・メモリ（enhanced SDRAM、ESDRAM）、シンクリンク・ダイナミック・ランダム・アクセス・メモリ（synchlink DRAM、SLDRAM）、およびダイレクト・ラムバス・ランダム・アクセス・メモリ（direct rambus RAM、DR RAM）が使用されうる。

バス1004は、データバスに加えて、電力バス、制御バス、およびステータス信号バスなどをさらに含んでもよい。しかしながら、明確な説明のために、図では様々なタイプのバスがバス1004として示されている。

プロセッサ1001は、メモリ1002に記憶されたコンピュータプログラムを実行するように構成され、プロセッサ1001は、前述の方法の実施形態におけるステップを実施するためにコンピュータプログラム10021を実行する。

本出願の一実施形態は、コンピュータ可読記憶媒体をさらに提供する。コンピュータ可読記憶媒体は命令を記憶し、命令は、前述の方法の実施形態におけるステップを実施するためにプロセッサによって実行される。

本出願の一実施形態は、命令を含むコンピュータプログラム製品をさらに提供する。コンピュータプログラム製品がコンピュータ上で動作するとき、コンピュータは、前述の方法の実施形態におけるステップを行うことが可能である。

本出願の実施形態で言及される「および／または」は、3つの関係が存在しうることを示すことを理解されたい。例えば、Aおよび／またはBは、Aのみが存在すること、AとBの両方が存在すること、およびBのみが存在することを示しうる。記号「／」は一般に、関連付けられた対象間の「または」関係を示す。

本出願における「少なくとも1つ」という用語は1つ以上を意味し、本出願における「複数の」という用語は2つまたは2つより多くのを意味する。例えば、「複数のプロパティ」は、2つまたは2つより多くのプロパティを意味する。

前述の実施形態の全部または一部は、ソフトウェア、ハードウェア、ファームウェア、またはこれらの任意の組み合わせを使用して実施されてもよい。ソフトウェアが、実施態様に使用されるとき、前述の実施形態の全部または一部は、コンピュータプログラム製品の形態で実施されてもよい。コンピュータプログラム製品は、1つ以上のコンピュータ命令を含む。コンピュータプログラム命令がコンピュータ上でロードまたは実行されるとき、本出願の実施形態によるプロセスまたは機能の全部または一部が生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、または他のプログラマブル装置であってもよい。コンピュータ命令は、コンピュータ可読記憶媒体に記憶されてもよいし、またはあるコンピュータ可読記憶媒体から他のコンピュータ可読記憶媒体に伝送されてもよい。例えば、コンピュータ命令は、有線（例えば、同軸ケーブル、光ファイバ、もしくはデジタル加入者回線（DSL））またはワイヤレス（例えば、赤外線、無線、もしくはマイクロ波）の方式で、あるウェブサイト、コンピュータ、サーバ、またはデータセンタから他のウェブサイト、コンピュータ、サーバ、またはデータセンタに伝送されてもよい。コンピュータ可読記憶媒体は、コンピュータによってアクセス可能な任意の使用可能な媒体、または1つ以上の使用可能な媒体を組み込んだ、サーバもしくはデータセンタなどのデータ記憶デバイスであってもよい。使用可能な媒体は、磁気媒体（例えば、フロッピーディスク、ハードディスク、もしくは磁気テープ）、光学媒体（例えば、DVD）、または半導体媒体であってもよい。半導体媒体は、ソリッドステートドライブ（solid state drive、SSD）であってもよい。

前述の説明は、本出願の任意選択の実施態様にすぎず、本出願の保護範囲はこれに限定されない。本出願に開示された技術的範囲内で当業者によって容易に考え出される任意の同等の修正例または置換例は、本出願の保護範囲内にあるものとする。したがって、本出願の保護範囲は、特許請求の範囲の保護範囲に従うものとする。

01 ハードウェア層
001 組み込みデバイス
02 OSインターフェース
002 組み込みデバイス、AUTOSAR開発ツール
0021 構成ツール
0022 生成ツール
03 サービス層
031 通信インターフェース
032 リソース管理モジュール
032a 解析サブモジュール
032b 管理サブモジュール
033 動作モジュール
04 アプリケーション層
1001 プロセッサ
1002 メモリ
1003 ネットワークインターフェース
1004 バス
10021 コンピュータプログラム

アプリケーションがAUTOSARに基づいて開発される場合、ユーザは、リモート端末（Telnet）もしくはセキュアシェル（secure shell、ssh）などのプロトコルを用いてデバイスにリモート接続し、コマンドラインを入力することによってデバイスのハードウェア形態を決定してもよいし、またはユーザは、ハードウェアマニュアルをチェックしてデバイスのハードウェア形態を決定してもよい。次に、ユーザは、ハードウェア形態に基づいて、AUTOSAR構成ツールにハードウェアリソースパラメータを手動で入力しうる。構成ツールは、ユーザによって入力されたハードウェアリソースパラメータに基づいて記述ファイルを生成してもよく、AUTOSAR生成ツールが、記述ファイルに基づいて構成ファイルおよび実行可能ファイルをさらに生成してもよい。

図3は、本出願の一実施形態によるパラメータ構成方法のフローチャートである。本方法は、図2に示されている適用シナリオに適用されうる。例えば、図2に示されている組み込みデバイス001は、AUTOSAR APを使用しうる。図1に示されているように、組み込みデバイス001は、ハードウェア層01、サービス層03、およびアプリケーション層04を含みうる。図2を参照されたい。本方法は、以下のステップを含む。

AUTOSARメタモデルは、AUTOSARシステムを記述するための言語を定義するための統一モデリング言語（unified modeling language、UML）モデルであり、テンプレートのグラフィカル表現である（テンプレートは、AUTOSARハードウェアおよびソフトウェアシステムを形成するためのソフトウェア構成要素およびECUなどの構造を定義する）。AUTOSARモデルは、AUTOSARメタモデルのインスタンスある。

本出願のこの実施形態では、ターゲットハードウェアリソースのポリシー構成項目は、第2のプロパティをさらに含みえ、第2のプロパティは、ターゲットハードウェアリソースを管理するための起動条件を示す。言い換えれば、サービス層は、ターゲットハードウェアリソースの動作ステータスが起動条件を満たすと決定した後に、ターゲットハードウェアリソースの動作ステータスを調整しうる。このようにして、ハードウェアリソースの動作ステータスを誤って調整することによって組み込みデバイスの性能が影響を受けることが防止されることができ、リソーススケジューリングの信頼性が保証される。

Claims (20)

1. 自動車オープンシステムアーキテクチャAUTOSARを用いる組み込みデバイスに適用されるパラメータ構成方法であって、前記組み込みデバイスは、ハードウェア層、サービス層、およびアプリケーション層を含み、前記方法は、
   前記サービス層によって、前記ハードウェア層のハードウェアリソースパラメータを取得するステップと、
   前記サービス層によって、前記ハードウェアリソースパラメータをAUTOSAR開発ツールに送信するステップであって、前記ハードウェアリソースパラメータは、実行可能ファイルおよび構成ファイルを生成するために前記AUTOSAR開発ツールによって使用され、前記実行可能ファイルおよび前記構成ファイルは、前記ハードウェア層において記憶される、ステップと、
   前記サービス層によって、前記構成ファイルに基づいて前記実行可能ファイルを動作させるステップと
   を含む、パラメータ構成方法。
2. 前記構成ファイルはリソース管理ポリシーを含み、前記方法は、
   前記サービス層によって前記リソース管理ポリシーに基づいて、前記ハードウェア層に含まれるハードウェアリソースの動作ステータスを調整するステップ
   をさらに含む、請求項1に記載の方法。
3. 前記リソース管理ポリシーは、ターゲットハードウェアリソースの識別子および第1のプロパティを含み、前記第1のプロパティは、前記ターゲットハードウェアリソースのリソース管理方式を示し、
   前記サービス層によって前記リソース管理ポリシーに基づいて、前記ハードウェア層に含まれるハードウェアリソースの動作ステータスを調整する前記ステップは、
   前記サービス層によって、前記第1のプロパティによって示される前記リソース管理方式に基づいて、前記識別子によって示される前記ターゲットハードウェアリソースの動作ステータスを調整するステップ
   を含む、請求項2に記載の方法。
4. 前記リソース管理ポリシーは第2のプロパティをさらに含み、前記第2のプロパティは、前記ターゲットハードウェアリソースを管理するための起動条件を示し、
   前記サービス層によって、前記第1のプロパティによって示される前記リソース管理方式に基づいて、前記識別子によって示される前記ターゲットハードウェアリソースの動作ステータスを調整する前記ステップは、
   前記サービス層が、前記識別子によって示される前記ターゲットハードウェアリソースの前記動作ステータスが前記第2のプロパティによって示される前記起動条件を満たすと決定した場合に、前記サービス層によって、前記第1のプロパティによって示される前記リソース管理方式に基づいて前記ターゲットハードウェアリソースの前記動作ステータスを調整するステップ
   を含む、請求項3に記載の方法。
5. 前記リソース管理方式は、前記ターゲットハードウェアリソースを無効化するステップ、または前記ターゲットハードウェアリソースの動作周波数を低減するステップを含む、請求項3または4に記載の方法。
6. 前記サービス層によって前記リソース管理ポリシーに基づいて、前記ハードウェア層に含まれるハードウェアリソースの動作ステータスを調整する前記ステップは、
   前記サービス層が、前記組み込みデバイスで状態切り替えが発生し、前記状態切り替えがハードウェアリソース調整条件を満たすことを検出した場合に、前記サービス層によって、前記リソース管理ポリシーに基づいて前記ハードウェアリソースの前記動作ステータスを調整するステップ
   を含む、請求項2から5のいずれか一項に記載の方法。
7. 前記サービス層によって、前記ハードウェア層のハードウェアリソースパラメータを取得する前記ステップは、
   前記サービス層によって、前記AUTOSAR開発ツールによって送信された構成コマンドを受信するステップと、
   前記サービス層によって、前記構成コマンドに従って前記ハードウェア層の前記ハードウェアリソースパラメータを取得するステップと
   を含む、請求項1から6のいずれか一項に記載の方法。
8. 前記ハードウェアリソースパラメータは、マシンパラメータおよびシステムパラメータを含む、請求項1から7のいずれか一項に記載の方法。
9. 組み込みデバイスであって、前記組み込みデバイスは、自動車オープンシステムアーキテクチャAUTOSARを使用し、前記組み込みデバイスは、ハードウェア層、サービス層、およびアプリケーション層を含み、前記サービス層は、
   前記ハードウェア層のハードウェアリソースパラメータを取得するように構成されたリソース管理モジュールと、
   前記ハードウェアリソースパラメータをAUTOSAR開発ツールに送信し、前記ハードウェアリソースパラメータは、実行可能ファイルおよび構成ファイルを生成するために前記AUTOSAR開発ツールによって使用され、前記実行可能ファイルおよび前記構成ファイルは、前記ハードウェア層において記憶される、ように構成された通信インターフェースと、
   前記構成ファイルに基づいて前記実行可能ファイルを動作させるように構成された動作モジュールと
   を含む、組み込みデバイス。
10. 前記構成ファイルはリソース管理ポリシーを含み、前記リソース管理モジュールは、
    前記リソース管理ポリシーに基づいて、前記ハードウェア層に含まれるハードウェアリソースの動作ステータスを調整する
    ようにさらに構成される、請求項9に記載のデバイス。
11. 前記リソース管理ポリシーは、ターゲットハードウェアリソースの識別子および第1のプロパティを含み、前記第1のプロパティは、前記ターゲットハードウェアリソースのリソース管理方式を示し、
    前記リソース管理モジュールは、
    前記第1のプロパティによって示される前記リソース管理方式に基づいて、前記識別子によって示される前記ターゲットハードウェアリソースの動作ステータスを調整する
    ように構成される、請求項10に記載のデバイス。
12. 前記リソース管理ポリシーは第2のプロパティをさらに含み、前記第2のプロパティは、前記ターゲットハードウェアリソースを管理するための起動条件を示し、
    前記リソース管理モジュールは、
    前記リソース管理モジュールが、前記識別子によって示される前記ターゲットハードウェアリソースの前記動作ステータスが前記第2のプロパティによって示される前記起動条件を満たすと決定した場合に、前記第1のプロパティによって示される前記リソース管理方式に基づいて前記ターゲットハードウェアリソースの前記動作ステータスを調整する
    ように構成される、請求項11に記載のデバイス。
13. 前記リソース管理方式は、前記ターゲットハードウェアリソースを無効化すること、または前記ターゲットハードウェアリソースの動作周波数を低減することを含む、請求項11または12に記載のデバイス。
14. 前記リソース管理モジュールは、
    前記リソース管理モジュールが、前記組み込みデバイスで状態切り替えが発生し、前記状態切り替えがハードウェアリソース調整条件を満たすことを検出した場合に、前記リソース管理ポリシーに基づいて前記ハードウェアリソースの前記動作ステータスを調整する
    ように構成される、請求項10から13のいずれか一項に記載のデバイス。
15. 前記リソース管理モジュールは、
    前記AUTOSAR開発ツールによって送信された構成コマンドを受信し、
    前記構成コマンドに従って前記ハードウェア層の前記ハードウェアリソースパラメータを取得する
    ように構成される、請求項9から14のいずれか一項に記載のデバイス。
16. 前記ハードウェアリソースパラメータは、マシンパラメータおよびシステムパラメータを含む、請求項9から15のいずれか一項に記載のデバイス。
17. 組み込みデバイスであって、前記組み込みデバイスは、自動車オープンシステムアーキテクチャAUTOSARを使用し、前記組み込みデバイスは、メモリおよびプロセッサを含み、
    前記メモリは、コンピュータプログラムを記憶するように構成され、
    前記プロセッサは、前記組み込みデバイスが請求項1から8のいずれか一項に記載の方法を行うことを可能にするために、前記メモリに記憶された前記コンピュータプログラムを実行するように構成される、
    組み込みデバイス。
18. パラメータ構成システムであって、前記システムは、AUTOSAR開発ツールと、請求項9から17のいずれか一項に記載の組み込みデバイスとを含み、
    前記AUTOSAR開発ツールは、前記組み込みデバイスのサービス層によって送信されたハードウェアリソースパラメータに基づいて実行可能ファイルおよび構成ファイルを生成するように構成される、
    パラメータ構成システム。
19. コンピュータ可読記憶媒体であって、前記コンピュータ可読記憶媒体は命令を記憶し、前記命令は、請求項1から8のいずれか一項に記載の方法を実施するためにプロセッサによって実行される、コンピュータ可読記憶媒体。
20. チップであって、前記チップは、プログラマブル論理回路および／またはプログラム命令を含み、動作するときに、前記チップは、請求項1から8のいずれか一項に記載の方法を実施するように構成される、チップ。