JP2023550936A - Ｉ／ｏデバイス・アクセス方法及び装置 - Google Patents

Ｉ／ｏデバイス・アクセス方法及び装置 Download PDF

Info

Publication number
JP2023550936A
JP2023550936A JP2023530559A JP2023530559A JP2023550936A JP 2023550936 A JP2023550936 A JP 2023550936A JP 2023530559 A JP2023530559 A JP 2023530559A JP 2023530559 A JP2023530559 A JP 2023530559A JP 2023550936 A JP2023550936 A JP 2023550936A
Authority
JP
Japan
Prior art keywords
devices
various
centralized controller
resource access
standard model
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2023530559A
Other languages
English (en)
Inventor
フゥ，タオ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of JP2023550936A publication Critical patent/JP2023550936A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40006—Architecture of a communication node
    • H04L12/40032—Details regarding a bus interface enhancer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • B60R16/0231—Circuits relating to the driving or the functioning of the vehicle
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40006—Architecture of a communication node
    • H04L12/40013—Details regarding a bus controller
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40078—Bus configuration
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/02—Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]

Abstract

この出願の実施形態は、Ｉ／Ｏデバイス・アクセス方法及び装置を開示する。本方法は、第１の集中型コントローラが、車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成し、様々なＩ／Ｏデバイスと標準モデルとの間のマッピング設定ファイルを生成することを含む。第１の集中型コントローラが、ユーザのアクセス動作に基づいてリソース・アクセス要求を生成し、リソース・アクセス要求は、ユーザによってアクセスされる第１のＩ／Ｏデバイスの第１の標準モデルを含む。第１の集中型コントローラが、マッピング設定ファイルに基づいて、第１のＩ／Ｏデバイスにリソース・アクセス要求を送信する。この出願の実施形態によれば、集中型コントローラによる異なるタイプのＩ／Ｏデバイスへのアクセスの柔軟性及び信頼性が改善され得る。

Description

この出願は、通信技術の分野に関連し、特に、Ｉ／Ｏデバイス・アクセス方法及び装置に関連する。
インテリジェント車両及び新しいエネルギー車の開発に伴い、自動車の電気電子アーキテクチャは分散型から集中型に進化し、コントローラを集中型にする傾向がある。現在の車両は、通常、数十から数百ものコントローラと、入力／出力（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ、略してＩ／Ｏ）インターフェースを有する数百のＩ／Ｏデバイスと、を有する。これらのＩ／Ｏデバイスは、温度センサ、湿度センサなどの様々なセンサであってもよいし、モータなどの様々なアクチュエータであってもよい。これらのＩ／Ｏデバイスは、コントローラ・エリア・ネットワーク（ｃｏｎｔｒｏｌｌｅｒ ａｒｅａ ｎｅｔｗｏｒｋ、略してＣＡＮ）インターフェース、ローカル・インターコネクト・ネットワーク（ｌｏｃａｌ ｉｎｔｅｒｃｏｎｎｅｃｔ ｎｅｔｗｏｒｋ、ＬＩＮ）インターフェース、パルス幅変調（ｐｕｌｓｅ ｗｉｄｔｈ ｍｏｄｕｌａｔｉｏｎ、略してＰＷＭ）インターフェース、Ｈブリッジ（Ｈ－ｂｒｉｄｇｅ ｂｕｓ、略してＨＢ）インターフェース、アナログ－デジタル（ａｎａｌｏｇ－ｔｏ－ｄｉｇｉｔａｌ、略してＡＤ）変換インターフェース、デジタル入力（ｄｉｇｉｔａｌ ｉｎｐｕｔ、略してＤＩ）インターフェース、デジタル出力（ｄｉｇｉｔａｌ ｏｕｔｐｕｔ、略してＤＯ）インターフェースなど、複数のタイプのインターフェースを有する。集中型コントローラによって様々なＩ／Ｏデバイスにアクセスするときに、柔軟性及び信頼性が比較的低くなる。
この出願の実施形態は、集中型コントローラによって異なるタイプのＩ／Ｏデバイスにアクセスするときに、柔軟性及び信頼性が比較的低いという技術的問題を解決するために、Ｉ／Ｏデバイス・アクセス方法及び装置を提供する。
第１の態様によれば、この出願の一実施形態は、Ｉ／Ｏデバイス・アクセス方法を提供し、本方法は、
第１の集中型コントローラが、車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成し、様々なＩ／Ｏデバイスと標準モデルとの間のマッピング設定ファイルを生成することを含んでもよい。
第１の集中型コントローラが、ユーザのアクセス動作に基づいてリソース・アクセス要求を生成し、リソース・アクセス要求は、ユーザによってアクセスされる第１のＩ／Ｏデバイスの第１の標準モデルを含む。
第１の集中型コントローラが、マッピング設定ファイルに基づいて、第１のＩ／Ｏデバイスにリソース・アクセス要求を送信する。
オブジェクト指向モデリングは、様々なＩ／Ｏデバイスに対して実行され、その結果、１つの標準モデルが、異なるモデル番号又は異なるインターフェースを有する複数のＩ／Ｏデバイスにマッピングされ得る。追加的に、Ｉ／Ｏデバイスにアクセスするときに、集中型コントローラは、Ｉ／Ｏデバイスに対応する標準モデルに対するリソース・アクセス要求を送信することができ、マッピング設定ファイルに基づいて、Ｉ／Ｏデバイスに正確にリソース・アクセス要求を送信して、Ｉ／Ｏデバイスへのアクセスを完了することができ、異なるベンダー、車両モデル、デバイス・モデル番号、又はインターフェース・タイプに基づいて調整を実行する必要がない。したがって、Ｉ／Ｏデバイスへのアクセスの柔軟性及び信頼性が大幅に改善される。
可能な実装では、第１の集中型コントローラが、車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成し、様々なＩ／Ｏデバイスと標準モデルとの間のマッピング設定ファイルを生成することは、
第１の集中型コントローラが、アプリケーションによってアクセスされる様々なＩ／Ｏデバイスのタイプに基づいて、アプリケーションのために車両内の様々なＩ／Ｏデバイス対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成することを含む。
第１の集中型コントローラが、様々なＩ／Ｏデバイスの物理ポートに基づいてＩ／Ｏデバイスに対して物理ポート・モデリングを実行し、標準モデルを制御するために使用される標準化データとＩ／Ｏデバイスを制御するために使用される制御データとの間の変換関係を設定する。
アップワード・モデリングは、アプリケーションが標準モデルにアクセスすることによってＩ／Ｏデバイスにアクセスすることを可能にする。ダウンワード・モデリングは、異なるインターフェースを有するＩ／Ｏデバイスを同じ物理ポートにマッピングすることを可能にし、異なるタイプのインターフェースを有するＩ／Ｏデバイスへのアクセスが、その物理ポートを通して実装され得る。異なるタイプのインターフェースを有するＩ／Ｏデバイスにアクセスするときに、標準モデルに対応する標準化データ及び制御デバイスに対応する制御データに対して、対応する変換が実行される。Ｉ／Ｏデバイスの物理ポートのタイプをシールドする効果を実装することができ、異なる車両モデルの開発中に上位層アプリケーションを変更せずに維持することができる。これは、開発の困難さを軽減し、アプリケーション層ソフトウェアの再利用度を改善し、車両の研究開発及び試験を容易にする。追加的に、ベンダー、車両モデル、モデル番号、又はインターフェースが変更されるときに、設定データのみを更新する必要がある。これはアップグレードに便利である。
可能な実装では、リソース・アクセス要求は、第１の標準モデルを制御するために使用される第１の標準化データをさらに含み、本方法は、以下をさらに含む。
第１の集中型コントローラが、変換関係に基づいて、第１の標準化データを第１のＩ／Ｏデバイスに対応する第１の制御データに変換する。
第１の集中型コントローラが、第１の制御データを第１のＩ／Ｏデバイスに送信する。
データ変換が実行される。異なるベンダーのものか、異なる車両モデルを有する車内のものか、又は異なるモデル番号若しくは異なるインターフェースを有するＩ／Ｏデバイスにアクセスするときに、データ間の変換関係のみを適応的に設定する必要がある。
可能な実装では、本方法は、以下をさらに含む。
第１の集中型コントローラが、第１のＩ／Ｏデバイスによって報告されたサンプリング・データを受信する。
第１の集中型コントローラは、変換関係に基づいて、サンプリング・データを第１の標準モデルに対応する第２の標準化データに変換する。
可能な実装では、第１の集中型コントローラが第２の集中型コントローラ下にある第２のＩ／Ｏデバイスにアクセスする必要があるときに、リソース・アクセス要求は、ユーザによってアクセスされる第２のＩ／Ｏデバイスの第２の標準モデルを含み、本方法は、以下をさらに含む。
第１の集中型コントローラが、第１の集中型コントローラと第２の集中型コントローラの間の通信層リンクを通して、第２のＩ／Ｏデバイスにリソース・アクセス要求を送信する。
このクロスノード・アクセス方式では、第２の集中型コントローラのアプリケーション層を修正する必要がなく、新しい通信インターフェースを追加する必要がない。これにより、クロスノード・アクセス効率が向上し、クロスノード・アクセスコストが削減される。
第２の態様によれば、この出願の一実施形態は、Ｉ／Ｏデバイス・アクセス装置を提供し、本装置は、
車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成し、様々なＩ／Ｏデバイスと標準モデルとの間のマッピング設定ファイルを生成することと、ユーザのアクセス動作に基づいて、リソース・アクセス要求を生成することであって、リソース・アクセス要求は、ユーザによってアクセスされる第１のＩ／Ｏデバイスの第１の標準モデルを含む、こととを行うように構成された処理ユニットと、
マッピング設定ファイルに基づいて、第１のＩ／Ｏデバイスにリソース・アクセス要求を送信することを行うように構成されたトランシーバ・ユニットと、を含んでもよい。
可能な実装では、処理ユニットは、具体的には、
アプリケーションによってアクセスされる様々なＩ／Ｏデバイスのタイプに基づいて、アプリケーションのために車両内の様々なＩ／Ｏデバイス対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成することと、
様々なＩ／Ｏデバイスの物理ポートに基づいてＩ／Ｏデバイスに対して物理ポート・モデリングを実行することと、標準モデルを制御するために使用される標準化データとＩ／Ｏデバイスを制御するために使用される制御データとの間の変換関係を設定することと、を行うように構成されている。
可能な実装では、リソース・アクセス要求は、第１の標準モデルを制御するために使用される第１の標準化データをさらに含む。
処理ユニットは、
変換関係に基づいて、第１の標準化データを第１のＩ／Ｏデバイスに対応する第１の制御データに変換することを行うようにさらに構成されている。
トランシーバ・ユニットは、第１の制御データを第１のＩ／Ｏデバイスに送信するようにさらに構成されている。
可能な実装では、トランシーバ・ユニットは、第１のＩ／Ｏデバイスによって報告されたサンプリング・データを受信することを行うようにさらに構成されている。
処理ユニットは、変換関係に基づいて、サンプリング・データを第１の標準モデルに対応する第２の標準化データに変換することを行うようにさらに構成されている。
可能な実装では、本装置が第２の集中型コントローラ下にある第２のＩ／Ｏデバイスにアクセスする必要があるときに、リソース・アクセス要求は、ユーザによってアクセスされる第２のＩ／Ｏデバイスの第２の標準モデルを含み、トランシーバ・ユニットは、
第１の集中型コントローラと第２の集中型コントローラの間の通信層リンクを通して、第２のＩ／Ｏデバイスにリソース・アクセス要求を送信すること行うようにさらに構成されている。
第３の態様によると、この出願の一実施形態は、Ｉ／Ｏデバイス・アクセス装置であって、本装置は、
車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成し、様々なＩ／Ｏデバイスと標準モデルとの間のマッピング設定ファイルを生成することを行うように構成されたデバイス抽象化層と、
ユーザのアクセス動作に基づいてリソース・アクセス要求を生成し、リソース・アクセス要求をデバイス抽象化層に送信するように構成されたアプリケーション層と、を含み、リソース・アクセス要求は、ユーザによってアクセスされる第１のＩ／Ｏデバイスの第１の標準モデルを含む。
デバイス抽象化層は、通信層にリソース・アクセス要求を送信するようにさらに構成されている。
通信層は、Ｉ／Ｏデバイスに対して入力／出力動作を実行するために、リソース・アクセス要求に基づいて、トランシーバを使用して制御コマンドをドライバ層に送信するように構成されている。
可能な実装では、ドライバ層は、制御コマンドに応答して、入力／出力動作を通して取得されたサンプリング・データを通信層に送信するように構成されている。
通信層は、サンプリング・データをデバイス抽象化層に送信するようにさらに構成されている。
デバイス抽象化層は、サンプリング・データを標準モデルに対応する標準化データに変換し、標準化データをアプリケーション層に送信するようにさらに構成されている。
第４の態様によれば、コンピュータ可読記憶媒体が提供され、コンピュータ・プログラムを記憶するように構成されている。コンピュータ・プログラムは、第１の態様又は第１の態様の可能な実装で方法を実行するために使用される命令を含む。
第５の態様によれば、コンピュータ・プログラム製品が提供される。コンピュータ・プログラム製品は、コンピュータ・プログラム・コードを含む。コンピュータ・プログラム製品がコンピュータ上で実行されるときに、コンピュータは、第１の態様及び第１の態様の可能のいずれかによる方法を実行することが可能となる。
この出願の実施例又は背景における技術的解決策をより明確に説明するために、以下、この出願の実施形態又は背景を説明するための添付の図面について説明する。
Ｉ／Ｏデバイスにアクセスするための既存のソフトウェア・アーキテクチャの概略図である。
この出願の一実施形態による、Ｉ／Ｏデバイス・アクセス方法の概略フローチャートである。
この出願の一実施形態による、Ｉ／Ｏデバイスにアクセスするためのソフトウェア・アーキテクチャの概略図である。
この出願の一実施形態による、Ｉ／Ｏデバイス・モデリング及び物理ポート・モデリングの概略図である。
この出願の一実施形態による、別のＩ／Ｏデバイス・アクセス方法の概略フローチャートである。
この出願の一実施形態による、Ｉ／Ｏデバイスにアクセスするための別のソフトウェア・アーキテクチャの概略図である。
この出願の一実施形態による、Ｉ／Ｏデバイスにアクセスするためのハードウェア・アーキテクチャの概略図である。
この出願の一実施形態による、Ｉ／Ｏデバイス・アクセス装置の概略構成図である。
この出願の一実施形態による、他のＩ／Ｏデバイス・アクセス装置の概略構成図である。
以下、この出願の実施態様における添付図面を参照して、この出願の実施形態を説明する。
この出願の明細書、特許請求の範囲及び添付の図面における「含む」、「有する」、又はその他のそれらの変形の用語は、非排他的な包含をカバーすることを意図している。例えば、一連のステップ又はユニットを含む、プロセス、方法、システム、製品、又はデバイスは、列挙されたステップ又はユニットに限定されず、任意選択で、さらに、列挙されていないステップ又はユニットを含むか、あるいは任意選択で、さらに、プロセス、方法、製品、又はデバイスの別の固有のステップ又はユニットを含む。
図１は、Ｉ／Ｏデバイスにアクセスするための既存のソフトウェア・アーキテクチャの概略図である。ソフトウェア・アーキテクチャは、アプリケーション層、通信層（ｃｏｍ層）、及びドライバ層を含む。
アプリケーション層１００は、Ｉ／Ｏデバイスにアクセスするためのプログラム・コードを記録し、関連するアプリケーションを実行するように構成されている。例えば、アプリケーションは、車両内のＩ／Ｏデバイスを制御するためのいくつかの制御アプリケーションであってもよいし、テストのためのいくつかのアプリケーションであっってもよい。ユーザがＩ／Ｏデバイスへのリソース・アクセスのための動作を実行するときに、アプリケーション層は通信層にリソース・アクセス要求を送信することがある。
通信層２００は、アプリケーション層によって送信されたリソース・アクセス要求を、トランシーバを使用してドライバ層に送信するように構成されている。
ドライバ層３００は、関連するＩ／Ｏデバイスを駆動するように構成されている。
このソフトウェア・アーキテクチャでは、Ｉ／Ｏデバイスにアクセスする必要があるときに、特定のＩ／Ｏデバイス、インターフェースのタイプ、ベンダー、車両モデルなどのデバイス間通信の詳細をアプリケーション層１０に示す必要がある。何らかの要因が変化するときに、アプリケーション層１０のアプリケーションも更新及び調整する必要がある。結果として、柔軟性及び信頼性が比較的低い。追加的に、このアーキテクチャでは、他の集中型コントローラによって制御されるＩ／Ｏデバイスにクロスノード方式でアクセスする必要があるときに、他の集中型コントローラと通信するための通信インターフェースを設定し、他の集中型コントローラの制御コードを変更する必要がある。結果として、アクセス効率が低い。
この観点から、この出願の実施形態は、Ｉ／Ｏデバイスへのアクセス及び制御の柔軟性及び信頼性を向上させるために、Ｉ／Ｏデバイス・アクセス方法及び装置を提供する。以下、図２～図９を参照して、この出願の実施形態で提供されるＩ／Ｏデバイス・アクセス方法及び装置について詳細に説明する。
図２は、この出願の一実施形態による、Ｉ／Ｏデバイス・アクセス方法の概略フローチャートである。本方法は、以下のステップを含む。
Ｓ２０１：第１の集中型コントローラが、車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成し、様々なＩ／Ｏデバイスと標準モデルとの間のマッピング設定ファイルを生成する。
車両内の様々なＩ／Ｏデバイスは、ワイパー、窓、ライト、シート、ドア、サンルーフ、トランクなど、車両内でアクセス又は制御され得る様々な部品を含んでもよく、距離センサ、温度センサ、光センサ、重力センサ、加速度センサなどの様々なセンサをさらに含んでもよい。追加的に、Ｉ／Ｏデバイスは、第１の集中型コントローラに類似する別の電子制御ユニット（ｅｌｅｃｔｒｏｎｉｃ ｃｏｎｔｒｏｌ ｕｎｉｔ、略してＥＣＵ）であってもよい。異なるベンダー及び車両モデルの場合、異なるインターフェース又はモデル番号を有するＩ／Ｏデバイスが使用されてもよい。アプリケーション層がＩ／Ｏデバイスにアクセスする必要があるときに、様々なベンダー、車両モデル、デバイス・モデル番号、及びインターフェース・タイプに基づいて適応を実行する必要がある。したがって、この出願のこの実施形態では、オブジェクト指向モデリングを様々なＩ／Ｏデバイス、例えば、ワイパーに対して実行してもよい。アプリケーションが、任意のベンダーのワイパー、任意の車両モデルを有する車両のワイパー、又は任意のモデル番号又はインターフェース・タイプを有するワイパーにアクセスするか、又はこれを制御する必要があるときに、「ワイパー」のそのような標準化されたオブジェクト指向モデルに対してリソース・アクセス要求が行われ得る。
Ｓ２０２：ユーザのアクセス動作に基づいてリソース・アクセス要求を生成し、リソース・アクセス要求は、ユーザによってアクセスされる第１のＩ／Ｏデバイスの第１の標準モデルを含む。
Ｓ２０３：マッピング設定ファイルに基づいて、第１のＩ／Ｏデバイスにリソース・アクセス要求を送信する。
集中型コントローラは、様々なＩ／Ｏデバイスと標準モデルとの間のマッピング設定ファイルを生成し、その結果、アプリケーションは、アクセス又は制御を完了するためにアクセス又は制御する必要があるＩ／Ｏデバイスにリソース・アクセス要求を正確に送達することができる。
この出願のこの実施形態では、オブジェクト指向モデリングは、様々なＩ／Ｏデバイスに対して実行され、その結果、１つの標準モデルが、異なるモデル番号又は異なるインターフェースを有する複数のＩ／Ｏデバイスにマッピングされ得る。追加的に、Ｉ／Ｏデバイスにアクセスするときに、集中型コントローラは、Ｉ／Ｏデバイスに対応する標準モデルに対するリソース・アクセス要求を送信することができ、マッピング設定ファイルに基づいて、Ｉ／Ｏデバイスに正確にリソース・アクセス要求を送信して、Ｉ／Ｏデバイスへのアクセスを完了することができ、異なるベンダー、車両モデル、デバイス・モデル番号、又はインターフェース・タイプに基づいて調整を実行する必要がない。したがって、Ｉ／Ｏデバイスへのアクセスの柔軟性及び信頼性が大幅に改善される。
図３は、この出願の一実施形態によるＩ／Ｏデバイスにアクセスするためのソフトウェア・アーキテクチャの概略図である。ソフトウェア・アーキテクチャは、
車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成し、様々なＩ／Ｏデバイスと標準モデルとの間のマッピング設定ファイルを生成することを行うように構成されたデバイス抽象化層１０と、
ユーザのアクセス動作に基づいてリソース・アクセス要求を生成し、リソース・アクセス要求をデバイス抽象化層１０に送信するように構成されたアプリケーション層２０と、を含み、リソース・アクセス要求は、ユーザによってアクセスされる第１のＩ／Ｏデバイスの第１の標準モデルを含む。
デバイス抽象化層１０は、通信層３０にリソース・アクセス要求を送信するようにさらに構成されている。
通信層３０は、Ｉ／Ｏデバイスに対する入力／出力動作を実行するために、リソース・アクセス要求に基づいて、トランシーバを使用して制御コマンドをドライバ層４０に送信するように構成されている。
ドライバ層４０は、トランシーバによって転送されたリソース・アクセス要求を受信し、Ｉ／Ｏデバイスを駆動して、入力／出力動作を完了するように構成されている。
図４は、この出願の一実施形態による、Ｉ／Ｏデバイス・モデリング及び物理ポート・モデリングの概略図である。
デバイス抽象化層は、デバイス抽象化モジュール１１と、ポート抽象化モジュール１２と、を含んでもよい。図４に示すように、デバイス抽象化モジュール１１は、アプリケーションによってアクセスされる様々なＩ／Ｏデバイスのタイプに基づいて、車両制御ユニット（ｖｅｈｉｃｌｅ ｃｏｎｔｒｏｌ ｕｎｉｔ、略してＶＣＵ）ソフトウェア、ボディ制御モジュール（ｂｏｄｙ ｃｏｎｔｒｏｌ ｍｏｄｕｌｅ、略してＢＣＭ）ソフトウェアなどのアプリケーションのために、車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成してもよい。すなわち、デバイス・モデリングは、ソフトウェア・アーキテクチャ全体でアップワードに実行される。
ポート抽象化層１２が、様々なＩ／Ｏデバイスの物理ポートに基づいてＩ／Ｏデバイスに対する物理ポート・モデリングを実行し、標準モデルを制御するために使用される標準化データとＩ／Ｏデバイスを制御するために使用される制御データとの間の変換関係を設定してもよい。すなわち、ポート・モデリングは、ソフトウェア・アーキテクチャ全体でダウンワードに実行される。データが変換された後、データは転送プレーンを通して転送される。言い換えれば、Ｉ／Ｏインターフェースはイーサネット・インターフェースに変換される。最後に、データは物理ポートを介して様々なＩ／Ｏデバイスに送信される。
アップワード・モデリングは、アプリケーションが標準モデルにアクセスすることによってＩ／Ｏデバイスにアクセスすることを可能にする。ダウンワード・モデリングは、異なるインターフェースを有するＩ／Ｏデバイスを同じ物理ポートにマッピングすることを可能にし、異なるタイプのインターフェースを有するＩ／Ｏデバイスへのアクセスが、その物理ポートを通して実装され得る。異なるタイプのインターフェースを有するＩ／Ｏデバイスにアクセスするときに、標準モデルに対応する標準化データ及び制御デバイスに対応する制御データに対して、対応する変換が実行される。
図２で説明したＩ／Ｏデバイス・アクセス方法を参照すると、第１の集中型コントローラによって送達されるデータと第１のＩ／Ｏデバイスによって報告されるデータに対して、対応する変換が実行されてもよい。
第１の集中型コントローラが第１のＩ／Ｏデバイスにアクセスする必要があるときに、リソース・アクセス要求は、第１の標準モデルを制御するために使用される第１の標準化データをさらに含む。
第１の集中型コントローラは、変換関係に基づいて、第１の標準化データを第１のＩ／Ｏデバイスに対応する第１の制御データに変換し、
第１の制御データを第１のＩ／Ｏデバイスに送信してもよい。
第１の集中型コントローラがデータを報告するように第１のＩ／Ｏデバイスに示すとき、又は第１のＩ／Ｏデバイスが能動的にデータを報告するときに、第１の集中型コントローラは、第１のＩ／Ｏデバイスによって報告されたサンプリング・データを受信し、
変換関係に基づいて、サンプリング・データを第１の標準モデルに対応する第２の標準化データに変換してもよい。
例えば、ベンダー、車両モデル、デバイス・モデル番号、又はインターフェース・タイプを変更する必要があるときに、管理アプリケーションなどの対応する設計ツールを使用して、ＡＤキャリブレーション設定に使用される温度及び／又はフィッティング式の変更、ＰＷＭ設定に使用される高低閾値及び／又は計算式の変更、出力設定に使用される高低閾値、高低エッジ設定及び／又は計算式の変更、ＣＡＮ ＤＢＣ設定に使用される信号オフセット及び／又は計算式の変更、ＤＩ設定に使用される切り替え及び／又は高低マッピングの変更を行ってもよい。次いで、Ｉ／Ｏデバイスへのリソース・アクセスを実行するときに、ポート抽象化モジュール１２は、完了した設定に基づいて、ＡＤフィッティング式による計算、ＰＷＭ周波数比に基づく変換、ＤＩ高低値マッピング、ＣＡＮ／ＬＩＮ信号変換、ハイサイド・ドライバとローサイド・ドライバの値マッピング、ＨＢ定電流値マッピング、又はＳＥＮＴバス・マッピングを実行して、データ変換を実装してもよい。
この実施形態における方法によれば、Ｉ／Ｏデバイスの物理ポートのタイプをシールドすることができ、異なる車両モデルの開発中に上位層アプリケーションを変更せずに維持することができる。これは、開発の困難さを軽減し、アプリケーション層ソフトウェアの再利用度を改善し、車両の研究開発及び試験を容易にする。追加的に、ベンダー、車両モデル、モデル番号、又はインターフェースが変更されるときに、設定データのみを更新する必要がある。これはアップグレードに便利である。
図２～図４で説明された方法及びアーキテクチャに基づいて、この出願の一実施形態は、クロスノードＩ／Ｏデバイス・アクセス方法をさらに提供する。図５は、この出願の本実施形態による、別のＩ／Ｏデバイス・アクセス方法の概略フローチャートである。本方法は、以下のステップを含む。
Ｓ５０１：第１の集中型コントローラが、車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成し、様々なＩ／Ｏデバイスと標準モデルとの間のマッピング設定ファイルを生成する。
Ｓ５０２：ユーザのアクセス動作に基づいてリソース・アクセス要求を生成し、リソース・アクセス要求は、ユーザによってアクセスされる第２のＩ／Ｏデバイスの第２の標準モデルを含む。
Ｓ５０３：第１の集中型コントローラが、第１の集中型コントローラと第２の集中型コントローラとの間の通信層リンクを通して、第２のＩ／Ｏデバイスにリソース・アクセス要求を送信する。
図５の方法に対応するソフトウェア・アーキテクチャの概略図については、図６を参照のこと。図６は、この出願の一実施形態による、Ｉ／Ｏデバイスにアクセスするための別のソフトウェア・アーキテクチャの概略図である。ソフトウェア・アーキテクチャは、第１の集中型コントローラ及び第２の集中型コントローラを含む。第１の集中型コントローラは、デバイス抽象化層１１０と、アプリケーション層１２０と、通信層１３０と、ドライバ層１４０と、を含み、第２のコントローラは、通信層２３０と、ドライバ層２４０と、を含む。
第２の集中型コントローラも、デバイス抽象化層２１０と、アプリケーション層２２０と、含んでもよいことに留意されたい。しかしながら、この出願のこの実施形態におけるクロスノードＩ／Ｏデバイス・アクセス方法では、アプリケーション層２２０を修正する必要がなく、新しい通信インターフェースを追加する必要がない。これにより、クロスノード・アクセス効率が向上し、クロスノード・アクセスコストが削減される。
図６に示すソフトウェア・アーキテクチャに基づいて、特定のＩ／Ｏデバイス・アクセス手順は、Ｉ／Ｏデバイスへのローカル・アクセスアクセスと、Ｉ／Ｏデバイスへのクロスノード・アクセスと、を含んでもよい。
ローカル・アクセス手順（第１の集中型コントローラが第１のＩ／Ｏデバイスにアクセスする）は、以下のようである。
アプリケーション層１２０は、リソース・アクセス要求を生成し、リソース・アクセス要求をデバイス抽象化層１１０に送信する。
デバイス抽象化層１１０は、通信層１３０にリソース・アクセス要求を送信する。このステップでは、デバイス抽象化層１１０は、リソース・アクセス要求における第１の標準化データを、第１のＩ／Ｏデバイスに対応する制御データに変換してもよい。
通信層１３０は、第１のＩ／Ｏデバイスに対するＩ／Ｏ動作を実行するために、トランシーバを使用して対応する制御コマンドをドライバ層１４０に送信するように構成されている。物理ポートが異なるため、ここでいうトランシーバは汎用入力／出力（ｇｅｎｅｒａｌ－ｐｕｒｐｏｓｅ ｉｎｐｕｔ／ｏｕｔｐｕｔ、略してＧＰＩＯ）トランシーバ、ＣＡＮトランシーバなどである。
ドライバ層１４０は、制御コマンドに応答して、第１のＩ／Ｏデバイスにアクセスし、Ｉ／Ｏ動作を通して取得されたサンプリング・データを通信層１３０に送信する。
通信層１３０は、サンプリング・データをデバイス抽象化層１３０に転送する。
デバイス抽象化層１３０は、アクセス・サンプリング・データを標準化する、すなわち、サンプリング・データを第１の標準モデルに対応する第２の標準化データに変換し、次いで、第２の標準化データをアプリケーション層１２０に転送する。
クロスノード・アクセス手順（例えば、第１の集中型コントローラ１が第２のＩ／Ｏデバイスにアクセスする）は、以下のようである。
アプリケーション層１２０は、リソース・アクセス要求を生成し、リソース・アクセス要求をデバイス抽象化層１１０に送信する。
デバイス抽象化層１１０は、通信層１３０にリソース・アクセス要求を送信する。このステップでは、デバイス抽象化層１１０は、リソース・アクセス要求における第１の標準化データを、第１のＩ／Ｏデバイスに対応する制御データに変換してもよい。
通信層１３０は、第１の集中型コントローラの通信層２３０にリソース・アクセス要求を送信する。
第２の集中型コントローラの通信層２３０は、第２のＩ／Ｏデバイスに対するＩ／Ｏ動作を実行するために対応する制御コマンドを送信する。
第２の集中型コントローラのドライバ層２４０は、制御コマンドに応答して、第２のＩ／Ｏデバイスにアクセスし、Ｉ／Ｏ動作によって取得されたサンプリング・データを通信層２３０に転送する。
次いで、第２の集中型コントローラの通信層２３０は、サンプリング・データを第１の集中型コントローラの通信層１３０に転送する。
通信層１３０は、サンプリング・データをデバイス抽象化層１３０に転送する。
デバイス抽象化層１３０は、サンプリング・データを標準化する、すなわち、サンプリング・データを第２の標準モデルに対応する標準化データに変換し、次いで、標準化データをアプリケーション層１２０に転送する。
前述のソフトウェア・アーキテクチャに対応するハードウェア・アーキテクチャについては、図７を参照のこと。図７は、この出願の一実施形態による、Ｉ／Ｏデバイスにアクセスするためのハードウェア・アーキテクチャの概略図である。図７に示すように、Ｉ／Ｏデバイス・アクセス装置は、第１の集中型コントローラと、第２の集中型コントローラと、を含む。２つの集中型コントローラは、イーサネット（Ｅｔｈｅｒｎｅｔ、略してＥＴＨ）を使用して接続される。第１の集中型コントローラは、第１のマイクロ・コントローラ・ユニット（ｍｉｃｒｏ ｃｏｎｔｒｏｌｌｅｒ ｕｎｉｔ、略してＭＣＵ）３１０と、第１のマイクロ処理ユニット（ｍｉｃｒｏ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、略してＭＰＵ）３２０と、第１のイーサネット切り替えモジュール（Ｅｔｈｅｒｎｅｔ ｓｗｉｔｃｈ、略してＬＳＷ）３３０と、デバイス抽象化モジュール３４０（デバイス抽象化モジュール３４０は、デバイス抽象化層に対応する機能モジュールであり、独立して配設されてもよいし、第１のＭＣＵ３２０又は第１のＭＰＵ３１０と統合されてもよい）と、を含む。第２の集中型コントローラは、第２のＭＰＵ４１０、第２のＭＣＵ４２０、及び第２のＬＳＷ４３０を含み（デバイス抽象化モジュール４４０を含んでも含まなくてもよい）。第１の集中型コントローラによってローカルにアクセスされるＩ／Ｏデバイスが第１のＩ／Ｏデバイス３５０であり、第２の集中型コントローラによってローカルにアクセスされるＩ／Ｏデバイスが第２のＩ／Ｏデバイス４５０である。
ＭＣＵは、高いリアルタイム性能と高いセキュリティ・レベルを有するアプリケーションと共に展開されてもよく、Ｉ／Ｏデバイスに対するリソース・アクセス及びデータ転送をさらに担当してもよい。ＭＰＵは、計算量の要件が高いＡＤＡＳなどのアプリケーションと共に展開されてもよい。ＬＳＷは、バックボーン・ネットワーク通信に使用される。
例えば、第１のＭＰＵ３１０は、衝突前警告機能などの自動運転関連アプリケーション機能と共に展開されてもよく、第１のＭＣＵ３２０は、ＶＣＵ機能と共に展開されてもよく、第２のＭＰＵ４１０は、高度運転支援システム（ａｄｖａｎｃｅｄ ｄｒｉｖｅｒ ａｓｓｉｓｔａｎｃｅ ｓｙｓｔｅｍｓ、略してＡＤＡＳ）機能と共に展開されてもよく、ＭＣＵ４２０は、バッテリ管理システム（ｂａｔｔｅｒｙ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ、ＢＭＳ）機能と共に展開されてもよい。
図７の破線矢印で示すように、第１のＩ／Ｏデバイス３５０がローカルにアクセスされるときに、第１のＩ／Ｏデバイス３５０のデータが第１のＭＰＵ３１０／第１のＭＣＵ３２０に転送されてもよいし、イーサネット・インターフェースを通して第２の集中型コントローラの第２のＭＰＵ４１０／第２のＭＣＵ４２０に転送されて、第２の集中型コントローラによる第１のＩ／Ｏデバイスへのクロスノード・アクセスを実装してもよい。
この実施形態における方法は、車載Ｉ／Ｏデバイスへのリソース・アクセスだけでなく、産業用Ｉ／Ｏデバイスへのリソース・アクセスにも適用してもよい。これは、この出願のこの実施形態において限定されない。
図８は、この出願の一実施形態による、Ｉ／Ｏデバイス・アクセス装置の概略構成図である。装置は、
車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成し、様々なＩ／Ｏデバイスと標準モデルとの間のマッピング設定ファイルを生成することと、ユーザのアクセス動作に基づいて、リソース・アクセス要求を生成することであって、リソース・アクセス要求は、ユーザによってアクセスされる第１のＩ／Ｏデバイスの第１の標準モデルを含む、こととを行うように構成された処理ユニット１０００と、
マッピング設定ファイルに基づいて、第１のＩ／Ｏデバイスにリソース・アクセス要求を送信することを行うように構成されたトランシーバ・ユニット２０００と、を含む。
任意選択で、処理ユニット１０００は、具体的には、
アプリケーションによってアクセスされる様々なＩ／Ｏデバイスのタイプに基づいて、アプリケーションのために車両内の様々なＩ／Ｏデバイス対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成することと、
様々なＩ／Ｏデバイスの物理ポートに基づいてＩ／Ｏデバイスに対する物理ポート・モデリングを実行することと、標準モデルを制御するために使用される標準化データとＩ／Ｏデバイスを制御するために使用される制御データとの間の変換関係を設定することと、を行うように構成されている。
任意選択で、リソース・アクセス要求は、第１の標準モデルを制御するために使用される第１の標準化データをさらに含む。
処理ユニット１０００は、
変換関係に基づいて、第１の標準化データを第１のＩ／Ｏデバイスに対応する第１の制御データに変換することを行うようにさらに構成されている。
トランシーバ・ユニット２０００は、第１の制御データを第１のＩ／Ｏデバイスに送信するようにさらに構成されている。
任意選択で、トランシーバ・ユニット２０００は、
第１のＩ／Ｏデバイスによって報告されたサンプリング・データを受信することを行うようにさらに構成されている。
処理ユニット１０００は、変換関係に基づいて、サンプリング・データを第１の標準モデルに対応する第２の標準化データに変換することを行うようにさらに構成されている。
任意選択で、本装置が第２の集中型コントローラ下にある第２のＩ／Ｏデバイスにアクセスする必要があるときに、リソース・アクセス要求は、ユーザによってアクセスされる第２のＩ／Ｏデバイスの第２の標準モデルを含み、トランシーバ・ユニット２０００は、
第１の集中型コントローラと第２の集中型コントローラの間の通信層リンクを通して、第２のＩ／Ｏデバイスにリソース・アクセス要求を送信すること行うようにさらに構成されている。
図９は、この出願の一実施形態による、他のＩ／Ｏデバイス・アクセス装置の概略構成図である。図９に示すように、装置は、プロセッサ１１１０、メモリ１１２０、及びトランシーバ１１３０を含んでもよい。プロセッサ１１１０、メモリ１１２０、及びトランシーバ１１３０は、バス１１４０を使用して接続される。メモリ１１２０は、命令を記憶するように構成されている。プロセッサ１１１０は、メモリ１１２０に記憶された命令を実行するように構成されており、図２～図６に対応する方法で第１の集中型コントローラによって実行されるステップを実装する。
プロセッサ１１１０は、メモリ１２０に記憶された命令を実行し、信号を受信するか、又は信号を送信するようにトランシーバ１１３０を制御し、前述の方法における装置によって実行されるステップを完了するように構成されている。メモリ１１２０は、プロセッサ１１１０に統合されていてもよいし、プロセッサ１１１０から独立して配設されてもよい。
一実装では、トランシーバ回路又は専用のトランシーバチップを使用して、トランシーバ・ユニット１１３０の機能が実装されることが考えられてもよく、専用の処理チップ、処理回路、プロセッサ、又は汎用チップを使用して、プロセッサ１１１０が実装されることが考えられてもよい。
別の実装では、この出願のこの実施形態で提供される装置が、汎用コンピュータを使用して実装されることが考えられてもよい。すなわち、プロセッサ１１１０及びトランシーバ１１３０の機能を実装するためのプログラム・コードがメモリ１１２０に記憶され、汎用プロセッサが、メモリ１１２０におけるコードを実行することによってプロセッサ１１１０及びトランシーバ１１３０の機能を実装する。
この出願のこの実施形態で提供される技術的解決策に関連する装置の概念、説明、詳細な説明、他のステップについては、上記の方法又は他の実施例の内容の説明を参照のこと。詳細は、ここでは再度説明されない。
この実施形態の別の形式では、コンピュータ可読記憶媒体が提供される。コンピュータ可読記憶媒体は、命令を記憶する。命令が実行されて、上述の方法の実施実施形態における第１の集中型コントローラによって実行される方法を実行する。
この実施形態の別の形式では、命令を含むコンピュータ・プログラム製品が提供される。命令が実行されて、上述の方法の実施実施形態における第１の集中型コントローラによって実行される方法を実行する。
当業者であれば、記載を容易にするために、図９は、１つのメモリ及び１つのプロセッサのみを示していることを理解してもよい。実際のコントローラでは、複数のプロセッサ及びメモリがあってもよい。メモリはまた、記憶媒体、記憶デバイスなどと呼ばれてもよい。これは、この出願のこの実施形態で限定されない。
この出願のこの実施形態では、プロセッサは、中央処理ユニット（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、略してＣＰＵ）であってもよいことを理解されたい。プロセッサはさらに、別の汎用プロセッサ、デジタル信号プロセッサ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ、略してＤＳＰ）、特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ、略してＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ｆｉｅｌｄ－ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ、略してＦＰＧＡ）、又は別のプログラマブル論理デバイス、ディスクリート・ゲート若しくはトランジスタ論理デバイス、ディスクリート・ハードウェア・コンポーネントなどであってもよい。
さらに、本発明のこの実施形態で言及されているメモリは、揮発性メモリ又は不揮発性メモリであってもよいし、揮発性メモリ及び不揮発性メモリを含んでいてもよいことを理解されたい。不揮発性メモリは、読み出し専用メモリ（ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ、略してＲＯＭ）、プログラマブル読み出し専用メモリ（ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ、略してＰＲＯＭ）、消去可能なプログラマブル読み出し専用メモリ（ｅｒａｓａｂｌｅ ＰＲＯＭ、略してＥＰＲＯＭ）、電気的に消去可能なプログラマブル読み出し専用メモリ（ｅｌｅｃｔｒｉｃａｌｌｙ ＥＰＲＯＭ、略してＥＥＰＲＯＭ）、又はフラッシュ・メモリであってもよい。揮発性メモリは、ランダム・アクセス・メモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ、ＲＡＭ）であってもよく、外部キャッシュとして使用される。限定的な説明ではなく、例えば、多くの形式のＲＡＭが使用されてもよく、例えば、スタティック・ランダム・アクセス・メモリ（ｓｔａｔｉｃ ＲＡＭ、略してＳＲＡＭ）、ダイナミック・ランダム・アクセス・メモリ（ｄｙｎａｍｉｃ ＲＡＭ、略してＤＲＡＭ）、同期ダイナミック・ランダム・アクセス・メモリ（ｓｙｎｃｈｒｏｎｏｕｓ ＤＲＡＭ、略してＳＤＲＡＭ）、ダブル・データ・レート同期ダイナミック・ランダム・アクセス・メモリ（ｄｏｕｂｌｅ ｄａｔａ ｒａｔｅ ＳＤＲＡＭ、略してＤＤＲ ＳＤＲＡＭ）、拡張同期ダイナミック・ランダム・アクセス・メモリ（ｅｎｈａｎｃｅｄ ＳＤＲＡＭ、略してＥＳＤＲＡＭ）、同期ダイナミック・ランダム・アクセス・メモリ（ｓｙｎｃｈｌｉｎｋ ＤＲＡＭ、略してＳＬＤＲＡＭ）、及びダイレクト・ランバス・ランダム・アクセス・メモリ（ｄｉｒｅｃｔ ｒａｍｂｕｓ ＲＡＭ、略してＤＲ ＲＡＭ）である。
プロセッサが、汎用プロセッサ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡ、又は別のプログラマブル論理デバイス、ディスクリート・ゲート若しくはトランジスタ論理デバイス、若しくはディスクリート・ハードウェア・コンポーネントであるときに、メモリ（記憶モジュール）がプロセッサに統合されることに留意されたい。
本明細書で説明されるメモリは、これらのメモリ及び別の適切なタイプの任意のメモリを含むが、これらに限定されないことに留意されたい。
バスは、データ・バスに追加して、電力バス、制御バス、ステータス信号バスなどをさらに含んでもよい。しかしながら、明確に説明するために、図における様々なバスは、バスとしてマーク付けされている。
この明細書における「第１」、「第２」、「第３」、「第４」及び様々な数字は、説明を容易にするための区別のために使用されるにすぎず、この出願の範囲を限定することを意図していないことをさらに理解されたい。
この明細書における「及び／又は」という用語は、関連付けられたオブジェクト間の関連付け関係のみを説明し、３つの関係が存在してもよいことを理解されたい。例えば、Ａ及び／又はＢは、Ａのみが存在し、Ａ及びＢの両方が存在し、Ｂのみが存在するという３つのケースを表してもよい。追加的に、本明細書における文字「／」は通常、関連付けられたオブジェクト間の「又は」関係を示す。
実装プロセスでは、前述の方法におけるステップは、プロセッサ内のハードウェアの統合論理回路を使用して、又はソフトウェアの形態で命令を使用して実装されてもよい。この出願の実施形態を参照して開示された方法のステップは、ハードウェア・プロセッサによって直接的に実行されてもよいし、プロセッサ内のハードウェア及びソフトウェア・モジュールの組み合わせを使用して実行されてもよい。ソフトウェア・モジュールは、ランダム・アクセス・メモリ、フラッシュ・メモリ、読み出し専用メモリ、プログラマブル読み出し専用メモリ、電気的に消去可能なプログラマブル・メモリ、レジスタなど、本技術分野における成熟した記憶媒体内に位置してもよい。記憶媒体は、メモリ内に位置し、プロセッサは、メモリ内の情報を読み出し、プロセッサにおいてハードウェアと組み合わせて前述の方法のステップを完了する。繰り返しを避けるために、詳細は、ここでは再度説明しない。
この出願の実施例で提供される方法によれば、この出願の実施形態は、システムをさらに提供する。システムは、第１の集中型コントローラと、様々なＩ／Ｏデバイスを含み、第２の集中型コントローラなどをさらに含んでもよい。
前述のプロセスのシーケンス番号は、本出願の様々な実施形態における実行シーケンスを意味しない。プロセスの実行シーケンスは、プロセスの機能及び内部論理に基づいて決定されるべきであり、この出願の実施形態の実装プロセスに対するあらゆる限定として解釈されるべきではない。
当業者は、この明細書に開示された実施形態を参照して説明される様々な例示的な論理ブロック（ｉｌｌｕｓｔｒａｔｉｖｅ ｌｏｇｉｃａｌ ｂｌｏｃｋ、略してＩＬＢ）及びステップが、電子ハードウェア又はコンピュータ・ソフトウェアと電子ハードウェアの組み合わせによって実装されてもよいことを認識するであろう。機能がハードウェアによって実行されるのか、コンピュータ・ソフトウェアに実行されるのかは、特定のアプリケーションと技術的解決策の設計上の制約条件に依存する。当業者であれば、特定のアプリケーションごとに、説明された機能を実装するために異なる方法を使用してもよいが、その実装がこの出願の範囲を超えると考えられるべきでない。
この出願で提供されるいくつかの実施形態では、開示されたシステム、装置、及び方法は、他の方式で実装され得ると理解されたい。例えば、説明された装置の実施形態は、一例にすぎない。例えば、ユニットへの分割は、単に論理機能分割であり、実際の実装においては他の分割であってもよい。例えば、複数のユニット又はコンポーネントが別のシステムに組み合わされたり、統合されたりしてもよいし、いくつかの特徴が無視されるか、又は実行されなくてもよい。追加的に、表示又は議論された相互結合、直接結合、又は通信接続は、いくつかのインターフェースを介して実装されてもよい。装置又はユニット間の間接結合又は通信接続は、電子的、機械的、又は他の形態において実装されてもよい。
別々の部分として説明されたユニットは、物理的に別個であってもなくてもよいし、ユニットとして表示されている部分が、物理的ユニットであってもなくてもよいし、１つの位置に位置していてもよいし、複数のネットワーク・ユニットに分散されていてもよい。ユニットの一部又は全部は、実施形態における解決策の目的を達成するために実際の要件に基づいて選択されてもよい。
追加的に、本出願の実施形態における機能ユニットは、１つの処理ユニットに統合されてもよいし、ユニットの各々は、物理的に単独で存在してもよいし、２つ以上のユニットは、１つのユニットに統合される。
前述の実施形態の全部又は一部は、ソフトウェア、ハードウェア、ファームウェア、又はそれらの任意の組み合わせを使用して実装されてもよい。ソフトウェアが前述の実施形態を実装するために使用されるときに、実施形態の全部又は一部は、コンピュータ・プログラム製品の形態で実装されてもよい。コンピュータ・プログラム製品は、１つ以上のコンピュータ命令を含む。コンピュータ・プログラム命令がロードされ、コンピュータ上で実行されるときに、この出願の実施形態による手順又は機能の全部又は部分的に生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータ・ネットワーク、又は他のプログラム可能なデバイスであってもよい。コンピュータ命令は、コンピュータ可読記憶媒体に記憶されてもよいし、１つのコンピュータ可読記憶媒体から別のコンピュータ可読記憶媒体に伝送されてもよい。例えば、コンピュータ命令は、ウェブサイト、コンピュータ、サーバ、又はデータ・センタから、有線（例えば、同軸ケーブル、光ファイバ、又はデジタル加入者線）又は無線（例えば、赤外線、ラジオ、又はマイクロ波）において別のウェブサイト、コンピュータ、サーバ、又はデータ・センタに伝送されてもよい。コンピュータ可読記憶媒体は、コンピュータがアクセス可能な任意の使用可能な媒体、又は１つ以上の使用可能な媒体を統合するデータ記憶デバイス、例えば、サーバ若しくはデータ・センタであってもよい。使用可能な媒体は、磁気媒体（例えば、フロッピー・ディスク、ハード・ディスク、又は磁気テープ）、光媒体（例えば、ＤＶＤ）、又は半導体媒体（例えば、ソリッド・ステート・ドライブ）などである。
前述の説明は、この出願の単に具体的な実装に過ぎないが、この出願の保護範囲を制限することを意図したものではない。この出願に開示された技術的範囲内で、当業者によって容易に理解することができる変更又は代替は、この出願の保護範囲に含まれるものとする。したがって、この出願の保護範囲は、特許請求の範囲の保護範囲に従うものとする。
この出願は、通信技術の分野に関連し、特に、Ｉ／Ｏデバイス・アクセス方法及び装置に関連する。
インテリジェント車両及び新しいエネルギー車の開発に伴い、自動車の電気電子アーキテクチャは分散型から集中型に進化し、コントローラを集中型にする傾向がある。現在の車両は、通常、数十から数百ものコントローラと、入力／出力（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ、略してＩ／Ｏ）インターフェースを有する数百のＩ／Ｏデバイスと、を有する。これらのＩ／Ｏデバイスは、温度センサ、湿度センサなどの様々なセンサであってもよいし、モータなどの様々なアクチュエータであってもよい。これらのＩ／Ｏデバイスは、コントローラ・エリア・ネットワーク（ｃｏｎｔｒｏｌｌｅｒ ａｒｅａ ｎｅｔｗｏｒｋ、略してＣＡＮ）インターフェース、ローカル・インターコネクト・ネットワーク（ｌｏｃａｌ ｉｎｔｅｒｃｏｎｎｅｃｔ ｎｅｔｗｏｒｋ、ＬＩＮ）インターフェース、パルス幅変調（ｐｕｌｓｅ ｗｉｄｔｈ ｍｏｄｕｌａｔｉｏｎ、略してＰＷＭ）インターフェース、Ｈブリッジ（Ｈ－ｂｒｉｄｇｅ ｂｕｓ、略してＨＢ）インターフェース、アナログ－デジタル（ａｎａｌｏｇ－ｔｏ－ｄｉｇｉｔａｌ、略してＡＤ）変換インターフェース、デジタル入力（ｄｉｇｉｔａｌ ｉｎｐｕｔ、略してＤＩ）インターフェース、デジタル出力（ｄｉｇｉｔａｌ ｏｕｔｐｕｔ、略してＤＯ）インターフェースなど、複数のタイプのインターフェースを有する。集中型コントローラによって様々なＩ／Ｏデバイスにアクセスするときに、柔軟性及び信頼性が比較的低くなる。
この出願の実施形態は、集中型コントローラによって異なるタイプのＩ／Ｏデバイスにアクセスするときに、柔軟性及び信頼性が比較的低いという技術的問題を解決するために、Ｉ／Ｏデバイス・アクセス方法及び装置を提供する。
第１の態様によれば、この出願の一実施形態は、Ｉ／Ｏデバイス・アクセス方法を提供し、本方法は、
第１の集中型コントローラが、車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成し、様々なＩ／Ｏデバイスと標準モデルとの間のマッピング設定ファイルを生成することを含んでもよい。
第１の集中型コントローラが、ユーザのアクセス動作に基づいてリソース・アクセス要求を生成し、リソース・アクセス要求は、ユーザによってアクセスされる第１のＩ／Ｏデバイスの第１の標準モデルを含む。
第１の集中型コントローラが、マッピング設定ファイルに基づいて、第１のＩ／Ｏデバイスにリソース・アクセス要求を送信する。
オブジェクト指向モデリングは、様々なＩ／Ｏデバイスに対して実行され、その結果、１つの標準モデルが、異なるモデル番号又は異なるインターフェースを有する複数のＩ／Ｏデバイスにマッピングされ得る。追加的に、Ｉ／Ｏデバイスにアクセスするときに、集中型コントローラは、Ｉ／Ｏデバイスに対応する標準モデルに対するリソース・アクセス要求を送信することができ、マッピング設定ファイルに基づいて、Ｉ／Ｏデバイスに正確にリソース・アクセス要求を送信して、Ｉ／Ｏデバイスへのアクセスを完了することができ、異なるベンダー、車両モデル、デバイス・モデル番号、又はインターフェース・タイプに基づいて調整を実行する必要がない。したがって、Ｉ／Ｏデバイスへのアクセスの柔軟性及び信頼性が大幅に改善される。
可能な実装では、第１の集中型コントローラが、車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成し、様々なＩ／Ｏデバイスと標準モデルとの間のマッピング設定ファイルを生成することは、
第１の集中型コントローラが、アプリケーションによってアクセスされる様々なＩ／Ｏデバイスのタイプに基づいて、アプリケーションのために車両内の様々なＩ／Ｏデバイス対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成することを含む。
第１の集中型コントローラが、様々なＩ／Ｏデバイスの物理ポートに基づいてＩ／Ｏデバイスに対して物理ポート・モデリングを実行し、標準モデルを制御するために使用される標準化データとＩ／Ｏデバイスを制御するために使用される制御データとの間の変換関係を設定する。
アップワード・モデリングは、アプリケーションが標準モデルにアクセスすることによってＩ／Ｏデバイスにアクセスすることを可能にする。ダウンワード・モデリングは、異なるインターフェースを有するＩ／Ｏデバイスを同じ物理ポートにマッピングすることを可能にし、異なるタイプのインターフェースを有するＩ／Ｏデバイスへのアクセスが、その物理ポートを通して実装され得る。異なるタイプのインターフェースを有するＩ／Ｏデバイスにアクセスするときに、標準モデルに対応する標準化データ及び制御デバイスに対応する制御データに対して、対応する変換が実行される。Ｉ／Ｏデバイスの物理ポートのタイプをシールドする効果を実装することができ、異なる車両モデルの開発中に上位層アプリケーションを変更せずに維持することができる。これは、開発の困難さを軽減し、アプリケーション層ソフトウェアの再利用度を改善し、車両の研究開発及び試験を容易にする。追加的に、ベンダー、車両モデル、モデル番号、又はインターフェースが変更されるときに、設定データのみを更新する必要がある。これはアップグレードに便利である。
可能な実装では、リソース・アクセス要求は、第１の標準モデルを制御するために使用される第１の標準化データをさらに含み、本方法は、以下をさらに含む。
第１の集中型コントローラが、変換関係に基づいて、第１の標準化データを第１のＩ／Ｏデバイスに対応する第１の制御データに変換する。
第１の集中型コントローラが、第１の制御データを第１のＩ／Ｏデバイスに送信する。
データ変換が実行される。異なるベンダーのものか、異なる車両モデルを有する車内のものか、又は異なるモデル番号若しくは異なるインターフェースを有するＩ／Ｏデバイスにアクセスするときに、データ間の変換関係のみを適応的に設定する必要がある。
可能な実装では、本方法は、以下をさらに含む。
第１の集中型コントローラが、第１のＩ／Ｏデバイスによって報告されたサンプリング・データを受信する。
第１の集中型コントローラは、変換関係に基づいて、サンプリング・データを第１の標準モデルに対応する第２の標準化データに変換する。
可能な実装では、第１の集中型コントローラが第２の集中型コントローラ下にある第２のＩ／Ｏデバイスにアクセスする必要があるときに、リソース・アクセス要求は、ユーザによってアクセスされる第２のＩ／Ｏデバイスの第２の標準モデルを含み、本方法は、以下をさらに含む。
第１の集中型コントローラが、第１の集中型コントローラと第２の集中型コントローラの間の通信層リンクを通して、第２のＩ／Ｏデバイスにリソース・アクセス要求を送信する。
このクロスノード・アクセス方式では、第２の集中型コントローラのアプリケーション層を修正する必要がなく、新しい通信インターフェースを追加する必要がない。これにより、クロスノード・アクセス効率が向上し、クロスノード・アクセスコストが削減される。
第２の態様によれば、この出願の一実施形態は、Ｉ／Ｏデバイス・アクセス装置を提供し、本装置は、
車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成し、様々なＩ／Ｏデバイスと標準モデルとの間のマッピング設定ファイルを生成することと、ユーザのアクセス動作に基づいて、リソース・アクセス要求を生成することであって、リソース・アクセス要求は、ユーザによってアクセスされる第１のＩ／Ｏデバイスの第１の標準モデルを含む、こととを行うように構成された処理ユニットと、
マッピング設定ファイルに基づいて、第１のＩ／Ｏデバイスにリソース・アクセス要求を送信することを行うように構成されたトランシーバ・ユニットと、を含んでもよい。
可能な実装では、処理ユニットは、具体的には、
アプリケーションによってアクセスされる様々なＩ／Ｏデバイスのタイプに基づいて、アプリケーションのために車両内の様々なＩ／Ｏデバイス対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成することと、
様々なＩ／Ｏデバイスの物理ポートに基づいてＩ／Ｏデバイスに対して物理ポート・モデリングを実行することと、標準モデルを制御するために使用される標準化データとＩ／Ｏデバイスを制御するために使用される制御データとの間の変換関係を設定することと、を行うように構成されている。
可能な実装では、リソース・アクセス要求は、第１の標準モデルを制御するために使用される第１の標準化データをさらに含む。
処理ユニットは、
変換関係に基づいて、第１の標準化データを第１のＩ／Ｏデバイスに対応する第１の制御データに変換することを行うようにさらに構成されている。
トランシーバ・ユニットは、第１の制御データを第１のＩ／Ｏデバイスに送信するようにさらに構成されている。
可能な実装では、トランシーバ・ユニットは、第１のＩ／Ｏデバイスによって報告されたサンプリング・データを受信することを行うようにさらに構成されている。
処理ユニットは、変換関係に基づいて、サンプリング・データを第１の標準モデルに対応する第２の標準化データに変換することを行うようにさらに構成されている。
可能な実装では、本装置が第２の集中型コントローラ下にある第２のＩ／Ｏデバイスにアクセスする必要があるときに、リソース・アクセス要求は、ユーザによってアクセスされる第２のＩ／Ｏデバイスの第２の標準モデルを含み、トランシーバ・ユニットは、
第１の集中型コントローラと第２の集中型コントローラの間の通信層リンクを通して、第２のＩ／Ｏデバイスにリソース・アクセス要求を送信すること行うようにさらに構成されている。
第３の態様によると、この出願の一実施形態は、Ｉ／Ｏデバイス・アクセス装置であって、本装置は、
車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成し、様々なＩ／Ｏデバイスと標準モデルとの間のマッピング設定ファイルを生成することを行うように構成されたデバイス抽象化層と、
ユーザのアクセス動作に基づいてリソース・アクセス要求を生成し、リソース・アクセス要求をデバイス抽象化層に送信するように構成されたアプリケーション層と、を含み、リソース・アクセス要求は、ユーザによってアクセスされる第１のＩ／Ｏデバイスの第１の標準モデルを含む。
デバイス抽象化層は、通信層にリソース・アクセス要求を送信するようにさらに構成されている。
通信層は、Ｉ／Ｏデバイスに対して入力／出力動作を実行するために、リソース・アクセス要求に基づいて、トランシーバを使用して制御コマンドをドライバ層に送信するように構成されている。
可能な実装では、ドライバ層は、制御コマンドに応答して、入力／出力動作を通して取得されたサンプリング・データを通信層に送信するように構成されている。
通信層は、サンプリング・データをデバイス抽象化層に送信するようにさらに構成されている。
デバイス抽象化層は、サンプリング・データを標準モデルに対応する標準化データに変換し、標準化データをアプリケーション層に送信するようにさらに構成されている。
第４の態様によれば、コンピュータ可読記憶媒体が提供され、コンピュータ・プログラムを記憶するように構成されている。コンピュータ・プログラムは、第１の態様又は第１の態様の可能な実装で方法を実行するために使用される命令を含む。
第５の態様によれば、コンピュータ・プログラム製品が提供される。コンピュータ・プログラム製品は、コンピュータ・プログラム・コードを含む。コンピュータ・プログラム製品がコンピュータ上で実行されるときに、コンピュータは、第１の態様及び第１の態様の可能のいずれかによる方法を実行することが可能となる。
この出願の実施例又は背景における技術的解決策をより明確に説明するために、以下、この出願の実施形態又は背景を説明するための添付の図面について説明する。
Ｉ／Ｏデバイスにアクセスするための既存のソフトウェア・アーキテクチャの概略図である。
この出願の一実施形態による、Ｉ／Ｏデバイス・アクセス方法の概略フローチャートである。
この出願の一実施形態による、Ｉ／Ｏデバイスにアクセスするためのソフトウェア・アーキテクチャの概略図である。
この出願の一実施形態による、Ｉ／Ｏデバイス・モデリング及び物理ポート・モデリングの概略図である。
この出願の一実施形態による、別のＩ／Ｏデバイス・アクセス方法の概略フローチャートである。
この出願の一実施形態による、Ｉ／Ｏデバイスにアクセスするための別のソフトウェア・アーキテクチャの概略図である。
この出願の一実施形態による、Ｉ／Ｏデバイスにアクセスするためのハードウェア・アーキテクチャの概略図である。
この出願の一実施形態による、Ｉ／Ｏデバイス・アクセス装置の概略構成図である。
この出願の一実施形態による、他のＩ／Ｏデバイス・アクセス装置の概略構成図である。
以下、この出願の実施態様における添付図面を参照して、この出願の実施形態を説明する。
この出願の明細書、特許請求の範囲及び添付の図面における「含む」、「有する」、又はその他のそれらの変形の用語は、非排他的な包含をカバーすることを意図している。例えば、一連のステップ又はユニットを含む、プロセス、方法、システム、製品、又はデバイスは、列挙されたステップ又はユニットに限定されず、任意選択で、さらに、列挙されていないステップ又はユニットを含むか、あるいは任意選択で、さらに、プロセス、方法、製品、又はデバイスの別の固有のステップ又はユニットを含む。
図１は、Ｉ／Ｏデバイスにアクセスするための既存のソフトウェア・アーキテクチャの概略図である。ソフトウェア・アーキテクチャは、アプリケーション層、通信層（ｃｏｍ層）、及びドライバ層を含む。
アプリケーション層１００は、Ｉ／Ｏデバイスにアクセスするためのプログラム・コードを記録し、関連するアプリケーションを実行するように構成されている。例えば、アプリケーションは、車両内のＩ／Ｏデバイスを制御するためのいくつかの制御アプリケーションであってもよいし、テストのためのいくつかのアプリケーションであっってもよい。ユーザがＩ／Ｏデバイスへのリソース・アクセスのための動作を実行するときに、アプリケーション層は通信層にリソース・アクセス要求を送信することがある。
通信層２００は、アプリケーション層によって送信されたリソース・アクセス要求を、トランシーバを使用してドライバ層に送信するように構成されている。
ドライバ層３００は、関連するＩ／Ｏデバイスを駆動するように構成されている。
このソフトウェア・アーキテクチャでは、Ｉ／Ｏデバイスにアクセスする必要があるときに、特定のＩ／Ｏデバイス、インターフェースのタイプ、ベンダー、車両モデルなどのデバイス間通信の詳細をアプリケーション層１０に示す必要がある。何らかの要因が変化するときに、アプリケーション層１０のアプリケーションも更新及び調整する必要がある。結果として、柔軟性及び信頼性が比較的低い。追加的に、このアーキテクチャでは、他の集中型コントローラによって制御されるＩ／Ｏデバイスにクロスノード方式でアクセスする必要があるときに、他の集中型コントローラと通信するための通信インターフェースを設定し、他の集中型コントローラの制御コードを変更する必要がある。結果として、アクセス効率が低い。
この観点から、この出願の実施形態は、Ｉ／Ｏデバイスへのアクセス及び制御の柔軟性及び信頼性を向上させるために、Ｉ／Ｏデバイス・アクセス方法及び装置を提供する。以下、図２～図９を参照して、この出願の実施形態で提供されるＩ／Ｏデバイス・アクセス方法及び装置について詳細に説明する。
図２は、この出願の一実施形態による、Ｉ／Ｏデバイス・アクセス方法の概略フローチャートである。本方法は、以下のステップを含む。
Ｓ２０１：第１の集中型コントローラが、車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成し、様々なＩ／Ｏデバイスと標準モデルとの間のマッピング設定ファイルを生成する。
車両内の様々なＩ／Ｏデバイスは、ワイパー、窓、ライト、シート、ドア、サンルーフ、トランクなど、車両内でアクセス又は制御され得る様々な部品を含んでもよく、距離センサ、温度センサ、光センサ、重力センサ、加速度センサなどの様々なセンサをさらに含んでもよい。追加的に、Ｉ／Ｏデバイスは、第１の集中型コントローラに類似する別の電子制御ユニット（ｅｌｅｃｔｒｏｎｉｃ ｃｏｎｔｒｏｌ ｕｎｉｔ、略してＥＣＵ）であってもよい。異なるベンダー及び車両モデルの場合、異なるインターフェース又はモデル番号を有するＩ／Ｏデバイスが使用されてもよい。アプリケーション層がＩ／Ｏデバイスにアクセスする必要があるときに、様々なベンダー、車両モデル、デバイス・モデル番号、及びインターフェース・タイプに基づいて適応を実行する必要がある。したがって、この出願のこの実施形態では、オブジェクト指向モデリングを様々なＩ／Ｏデバイス、例えば、ワイパーに対して実行してもよい。アプリケーションが、任意のベンダーのワイパー、任意の車両モデルを有する車両のワイパー、又は任意のモデル番号又はインターフェース・タイプを有するワイパーにアクセスするか、又はこれを制御する必要があるときに、「ワイパー」のそのような標準化されたオブジェクト指向モデルに対してリソース・アクセス要求が行われ得る。
Ｓ２０２：ユーザのアクセス動作に基づいてリソース・アクセス要求を生成し、リソース・アクセス要求は、ユーザによってアクセスされる第１のＩ／Ｏデバイスの第１の標準モデルを含む。
Ｓ２０３：マッピング設定ファイルに基づいて、第１のＩ／Ｏデバイスにリソース・アクセス要求を送信する。
集中型コントローラは、様々なＩ／Ｏデバイスと標準モデルとの間のマッピング設定ファイルを生成し、その結果、アプリケーションは、アクセス又は制御を完了するためにアクセス又は制御する必要があるＩ／Ｏデバイスにリソース・アクセス要求を正確に送達することができる。
この出願のこの実施形態では、オブジェクト指向モデリングは、様々なＩ／Ｏデバイスに対して実行され、その結果、１つの標準モデルが、異なるモデル番号又は異なるインターフェースを有する複数のＩ／Ｏデバイスにマッピングされ得る。追加的に、Ｉ／Ｏデバイスにアクセスするときに、集中型コントローラは、Ｉ／Ｏデバイスに対応する標準モデルに対するリソース・アクセス要求を送信することができ、マッピング設定ファイルに基づいて、Ｉ／Ｏデバイスに正確にリソース・アクセス要求を送信して、Ｉ／Ｏデバイスへのアクセスを完了することができ、異なるベンダー、車両モデル、デバイス・モデル番号、又はインターフェース・タイプに基づいて調整を実行する必要がない。したがって、Ｉ／Ｏデバイスへのアクセスの柔軟性及び信頼性が大幅に改善される。
図３は、この出願の一実施形態によるＩ／Ｏデバイスにアクセスするためのソフトウェア・アーキテクチャの概略図である。ソフトウェア・アーキテクチャは、
車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成し、様々なＩ／Ｏデバイスと標準モデルとの間のマッピング設定ファイルを生成することを行うように構成されたデバイス抽象化層１０と、
ユーザのアクセス動作に基づいてリソース・アクセス要求を生成し、リソース・アクセス要求をデバイス抽象化層１０に送信するように構成されたアプリケーション層２０と、を含み、リソース・アクセス要求は、ユーザによってアクセスされる第１のＩ／Ｏデバイスの第１の標準モデルを含む。
デバイス抽象化層１０は、通信層３０にリソース・アクセス要求を送信するようにさらに構成されている。
通信層３０は、Ｉ／Ｏデバイスに対する入力／出力動作を実行するために、リソース・アクセス要求に基づいて、トランシーバを使用して制御コマンドをドライバ層４０に送信するように構成されている。
ドライバ層４０は、トランシーバによって転送されたリソース・アクセス要求を受信し、Ｉ／Ｏデバイスを駆動して、入力／出力動作を完了するように構成されている。
図４は、この出願の一実施形態による、Ｉ／Ｏデバイス・モデリング及び物理ポート・モデリングの概略図である。
デバイス抽象化層は、デバイス抽象化モジュール１１と、ポート抽象化モジュール１２と、を含んでもよい。図４に示すように、デバイス抽象化モジュール１１は、アプリケーションによってアクセスされる様々なＩ／Ｏデバイスのタイプに基づいて、車両制御ユニット（ｖｅｈｉｃｌｅ ｃｏｎｔｒｏｌ ｕｎｉｔ、略してＶＣＵ）ソフトウェア、ボディ制御モジュール（ｂｏｄｙ ｃｏｎｔｒｏｌ ｍｏｄｕｌｅ、略してＢＣＭ）ソフトウェアなどのアプリケーションのために、車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成してもよい。すなわち、デバイス・モデリングは、ソフトウェア・アーキテクチャ全体でアップワードに実行される。
ポート抽象化層１２が、様々なＩ／Ｏデバイスの物理ポートに基づいてＩ／Ｏデバイスに対する物理ポート・モデリングを実行し、標準モデルを制御するために使用される標準化データとＩ／Ｏデバイスを制御するために使用される制御データとの間の変換関係を設定してもよい。すなわち、ポート・モデリングは、ソフトウェア・アーキテクチャ全体でダウンワードに実行される。データが変換された後、データは転送プレーンを通して転送される。言い換えれば、Ｉ／Ｏインターフェースはイーサネット・インターフェースに変換される。最後に、データは物理ポートを介して様々なＩ／Ｏデバイスに送信される。
アップワード・モデリングは、アプリケーションが標準モデルにアクセスすることによってＩ／Ｏデバイスにアクセスすることを可能にする。ダウンワード・モデリングは、異なるインターフェースを有するＩ／Ｏデバイスを同じ物理ポートにマッピングすることを可能にし、異なるタイプのインターフェースを有するＩ／Ｏデバイスへのアクセスが、その物理ポートを通して実装され得る。異なるタイプのインターフェースを有するＩ／Ｏデバイスにアクセスするときに、標準モデルに対応する標準化データ及び制御デバイスに対応する制御データに対して、対応する変換が実行される。
図２で説明したＩ／Ｏデバイス・アクセス方法を参照すると、第１の集中型コントローラによって送達されるデータと第１のＩ／Ｏデバイスによって報告されるデータに対して、対応する変換が実行されてもよい。
第１の集中型コントローラが第１のＩ／Ｏデバイスにアクセスする必要があるときに、リソース・アクセス要求は、第１の標準モデルを制御するために使用される第１の標準化データをさらに含む。
第１の集中型コントローラは、変換関係に基づいて、第１の標準化データを第１のＩ／Ｏデバイスに対応する第１の制御データに変換し、
第１の制御データを第１のＩ／Ｏデバイスに送信してもよい。
第１の集中型コントローラがデータを報告するように第１のＩ／Ｏデバイスに示すとき、又は第１のＩ／Ｏデバイスが能動的にデータを報告するときに、第１の集中型コントローラは、第１のＩ／Ｏデバイスによって報告されたサンプリング・データを受信し、
変換関係に基づいて、サンプリング・データを第１の標準モデルに対応する第２の標準化データに変換してもよい。
例えば、ベンダー、車両モデル、デバイス・モデル番号、又はインターフェース・タイプを変更する必要があるときに、管理アプリケーションなどの対応する設計ツールを使用して、ＡＤキャリブレーション設定に使用される温度及び／又はフィッティング式の変更、ＰＷＭ設定に使用される高低閾値及び／又は計算式の変更、出力設定に使用される高低閾値、高低エッジ設定及び／又は計算式の変更、ＣＡＮ ＤＢＣ設定に使用される信号オフセット及び／又は計算式の変更、ＤＩ設定に使用される切り替え及び／又は高低マッピングの変更を行ってもよい。次いで、Ｉ／Ｏデバイスへのリソース・アクセスを実行するときに、ポート抽象化モジュール１２は、完了した設定に基づいて、ＡＤフィッティング式による計算、ＰＷＭ周波数比に基づく変換、ＤＩ高低値マッピング、ＣＡＮ／ＬＩＮ信号変換、ハイサイド・ドライバとローサイド・ドライバの値マッピング、ＨＢ定電流値マッピング、又はＳＥＮＴバス・マッピングを実行して、データ変換を実装してもよい。
この実施形態における方法によれば、Ｉ／Ｏデバイスの物理ポートのタイプをシールドすることができ、異なる車両モデルの開発中に上位層アプリケーションを変更せずに維持することができる。これは、開発の困難さを軽減し、アプリケーション層ソフトウェアの再利用度を改善し、車両の研究開発及び試験を容易にする。追加的に、ベンダー、車両モデル、モデル番号、又はインターフェースが変更されるときに、設定データのみを更新する必要がある。これはアップグレードに便利である。
図２～図４で説明された方法及びアーキテクチャに基づいて、この出願の一実施形態は、クロスノードＩ／Ｏデバイス・アクセス方法をさらに提供する。図５は、この出願の本実施形態による、別のＩ／Ｏデバイス・アクセス方法の概略フローチャートである。本方法は、以下のステップを含む。
Ｓ５０１：第１の集中型コントローラが、車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成し、様々なＩ／Ｏデバイスと標準モデルとの間のマッピング設定ファイルを生成する。
Ｓ５０２：ユーザのアクセス動作に基づいてリソース・アクセス要求を生成し、リソース・アクセス要求は、ユーザによってアクセスされる第２のＩ／Ｏデバイスの第２の標準モデルを含む。
Ｓ５０３：第１の集中型コントローラが、第１の集中型コントローラと第２の集中型コントローラとの間の通信層リンクを通して、第２のＩ／Ｏデバイスにリソース・アクセス要求を送信する。
図５の方法に対応するソフトウェア・アーキテクチャの概略図については、図６を参照のこと。図６は、この出願の一実施形態による、Ｉ／Ｏデバイスにアクセスするための別のソフトウェア・アーキテクチャの概略図である。ソフトウェア・アーキテクチャは、第１の集中型コントローラ及び第２の集中型コントローラを含む。第１の集中型コントローラは、デバイス抽象化層１１０と、アプリケーション層１２０と、通信層１３０と、ドライバ層１４０と、を含み、第２のコントローラは、通信層２３０と、ドライバ層２４０と、を含む。
第２の集中型コントローラも、デバイス抽象化層２１０と、アプリケーション層２２０と、含んでもよいことに留意されたい。しかしながら、この出願のこの実施形態におけるクロスノードＩ／Ｏデバイス・アクセス方法では、アプリケーション層２２０を修正する必要がなく、新しい通信インターフェースを追加する必要がない。これにより、クロスノード・アクセス効率が向上し、クロスノード・アクセスコストが削減される。
図６に示すソフトウェア・アーキテクチャに基づいて、特定のＩ／Ｏデバイス・アクセス手順は、Ｉ／Ｏデバイスへのローカル・アクセスアクセスと、Ｉ／Ｏデバイスへのクロスノード・アクセスと、を含んでもよい。
ローカル・アクセス手順（第１の集中型コントローラが第１のＩ／Ｏデバイスにアクセスする）は、以下のようである。
アプリケーション層１２０は、リソース・アクセス要求を生成し、リソース・アクセス要求をデバイス抽象化層１１０に送信する。
デバイス抽象化層１１０は、通信層１３０にリソース・アクセス要求を送信する。このステップでは、デバイス抽象化層１１０は、リソース・アクセス要求における第１の標準化データを、第１のＩ／Ｏデバイスに対応する制御データに変換してもよい。
通信層１３０は、第１のＩ／Ｏデバイスに対するＩ／Ｏ動作を実行するために、トランシーバを使用して対応する制御コマンドをドライバ層１４０に送信するように構成されている。物理ポートが異なるため、ここでいうトランシーバは汎用入力／出力（ｇｅｎｅｒａｌ－ｐｕｒｐｏｓｅ ｉｎｐｕｔ／ｏｕｔｐｕｔ、略してＧＰＩＯ）トランシーバ、ＣＡＮトランシーバなどである。
ドライバ層１４０は、制御コマンドに応答して、第１のＩ／Ｏデバイスにアクセスし、Ｉ／Ｏ動作を通して取得されたサンプリング・データを通信層１３０に送信する。
通信層１３０は、サンプリング・データをデバイス抽象化層１１０に転送する。
デバイス抽象化層１１０は、アクセス・サンプリング・データを標準化する、すなわち、サンプリング・データを第１の標準モデルに対応する第２の標準化データに変換し、次いで、第２の標準化データをアプリケーション層１２０に転送する。
クロスノード・アクセス手順（例えば、第１の集中型コントローラ１が第２のＩ／Ｏデバイスにアクセスする）は、以下のようである。
アプリケーション層１２０は、リソース・アクセス要求を生成し、リソース・アクセス要求をデバイス抽象化層１１０に送信する。
デバイス抽象化層１１０は、通信層１３０にリソース・アクセス要求を送信する。このステップでは、デバイス抽象化層１１０は、リソース・アクセス要求における第１の標準化データを、第１のＩ／Ｏデバイスに対応する制御データに変換してもよい。
通信層１３０は、第１の集中型コントローラの通信層２３０にリソース・アクセス要求を送信する。
第２の集中型コントローラの通信層２３０は、第２のＩ／Ｏデバイスに対するＩ／Ｏ動作を実行するために対応する制御コマンドを送信する。
第２の集中型コントローラのドライバ層２４０は、制御コマンドに応答して、第２のＩ／Ｏデバイスにアクセスし、Ｉ／Ｏ動作によって取得されたサンプリング・データを通信層２３０に転送する。
次いで、第２の集中型コントローラの通信層２３０は、サンプリング・データを第１の集中型コントローラの通信層１３０に転送する。
通信層１３０は、サンプリング・データをデバイス抽象化層１３０に転送する。
デバイス抽象化層１１０は、サンプリング・データを標準化する、すなわち、サンプリング・データを第２の標準モデルに対応する標準化データに変換し、次いで、標準化データをアプリケーション層１２０に転送する。
前述のソフトウェア・アーキテクチャに対応するハードウェア・アーキテクチャについては、図７を参照のこと。図７は、この出願の一実施形態による、Ｉ／Ｏデバイスにアクセスするためのハードウェア・アーキテクチャの概略図である。図７に示すように、Ｉ／Ｏデバイス・アクセス装置は、第１の集中型コントローラと、第２の集中型コントローラと、を含む。２つの集中型コントローラは、イーサネット（Ｅｔｈｅｒｎｅｔ、略してＥＴＨ）を使用して接続される。第１の集中型コントローラは、第１のマイクロ処理ユニット（ｍｉｃｒｏ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、略してＭＰＵ）３１０と、第１のマイクロ・コントロール・ユニット（ｍｉｃｒｏ ｃｏｎｔｒｏｌ ｕｎｉｔ、略してＭＣＵ）３２０と、第１のイーサネット切り替えモジュール（ＬＡＮ ｓｗｉｔｃｈ、略してＬＳＷ）３３０と、デバイス抽象化モジュール３４０（デバイス抽象化モジュール３４０は、デバイス抽象化層に対応する機能モジュールであり、独立して配設されてもよいし、第１のＭＣＵ３２０又は第１のＭＰＵ３１０と統合されてもよい）と、を含む。第２の集中型コントローラは、第２のＭＰＵ４１０、第２のＭＣＵ４２０、及び第２のＬＳＷ４３０を含み（デバイス抽象化モジュール４４０を含んでも含まなくてもよい）。第１の集中型コントローラによってローカルにアクセスされるＩ／Ｏデバイスが第１のＩ／Ｏデバイス３５０であり、第２の集中型コントローラによってローカルにアクセスされるＩ／Ｏデバイスが第２のＩ／Ｏデバイス４５０である。
ＭＣＵは、高いリアルタイム性能と高いセキュリティ・レベルを有するアプリケーションと共に展開されてもよく、Ｉ／Ｏデバイスに対するリソース・アクセス及びデータ転送をさらに担当してもよい。ＭＰＵは、計算量の要件が高いＡＤＡＳなどのアプリケーションと共に展開されてもよい。ＬＳＷは、バックボーン・ネットワーク通信に使用される。
例えば、第１のＭＰＵ３１０は、衝突前警告機能などの自動運転関連アプリケーション機能と共に展開されてもよく、第１のＭＣＵ３２０は、ＶＣＵ機能と共に展開されてもよく、第２のＭＰＵ４１０は、高度運転支援システム（ａｄｖａｎｃｅｄ ｄｒｉｖｅｒ ａｓｓｉｓｔａｎｃｅ ｓｙｓｔｅｍｓ、略してＡＤＡＳ）機能と共に展開されてもよく、ＭＣＵ４２０は、バッテリ管理システム（ｂａｔｔｅｒｙ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ、ＢＭＳ）機能と共に展開されてもよい。
図７の破線矢印で示すように、第１のＩ／Ｏデバイス３５０がローカルにアクセスされるときに、第１のＩ／Ｏデバイス３５０のデータが第１のＭＰＵ３１０／第１のＭＣＵ３２０に転送されてもよいし、イーサネット・インターフェースを通して第２の集中型コントローラの第２のＭＰＵ４１０／第２のＭＣＵ４２０に転送されて、第２の集中型コントローラによる第１のＩ／Ｏデバイスへのクロスノード・アクセスを実装してもよい。
この実施形態における方法は、車載Ｉ／Ｏデバイスへのリソース・アクセスだけでなく、産業用Ｉ／Ｏデバイスへのリソース・アクセスにも適用してもよい。これは、この出願のこの実施形態において限定されない。
図８は、この出願の一実施形態による、Ｉ／Ｏデバイス・アクセス装置の概略構成図である。装置は、
車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成し、様々なＩ／Ｏデバイスと標準モデルとの間のマッピング設定ファイルを生成することと、ユーザのアクセス動作に基づいて、リソース・アクセス要求を生成することであって、リソース・アクセス要求は、ユーザによってアクセスされる第１のＩ／Ｏデバイスの第１の標準モデルを含む、こととを行うように構成された処理ユニット１０００と、
マッピング設定ファイルに基づいて、第１のＩ／Ｏデバイスにリソース・アクセス要求を送信することを行うように構成されたトランシーバ・ユニット２０００と、を含む。
任意選択で、処理ユニット１０００は、具体的には、
アプリケーションによってアクセスされる様々なＩ／Ｏデバイスのタイプに基づいて、アプリケーションのために車両内の様々なＩ／Ｏデバイス対してオブジェクト指向モデリングを実行して、様々なＩ／Ｏデバイスの標準モデルを生成することと、
様々なＩ／Ｏデバイスの物理ポートに基づいてＩ／Ｏデバイスに対する物理ポート・モデリングを実行することと、標準モデルを制御するために使用される標準化データとＩ／Ｏデバイスを制御するために使用される制御データとの間の変換関係を設定することと、を行うように構成されている。
任意選択で、リソース・アクセス要求は、第１の標準モデルを制御するために使用される第１の標準化データをさらに含む。
処理ユニット１０００は、
変換関係に基づいて、第１の標準化データを第１のＩ／Ｏデバイスに対応する第１の制御データに変換することを行うようにさらに構成されている。
トランシーバ・ユニット２０００は、第１の制御データを第１のＩ／Ｏデバイスに送信するようにさらに構成されている。
任意選択で、トランシーバ・ユニット２０００は、
第１のＩ／Ｏデバイスによって報告されたサンプリング・データを受信することを行うようにさらに構成されている。
処理ユニット１０００は、変換関係に基づいて、サンプリング・データを第１の標準モデルに対応する第２の標準化データに変換することを行うようにさらに構成されている。
任意選択で、本装置が第２の集中型コントローラ下にある第２のＩ／Ｏデバイスにアクセスする必要があるときに、リソース・アクセス要求は、ユーザによってアクセスされる第２のＩ／Ｏデバイスの第２の標準モデルを含み、トランシーバ・ユニット２０００は、
第１の集中型コントローラと第２の集中型コントローラの間の通信層リンクを通して、第２のＩ／Ｏデバイスにリソース・アクセス要求を送信すること行うようにさらに構成されている。
図９は、この出願の一実施形態による、他のＩ／Ｏデバイス・アクセス装置の概略構成図である。図９に示すように、装置は、プロセッサ１１１０、メモリ１１２０、及びトランシーバ１１３０を含んでもよい。プロセッサ１１１０、メモリ１１２０、及びトランシーバ１１３０は、バス１１４０を使用して接続される。メモリ１１２０は、命令を記憶するように構成されている。プロセッサ１１１０は、メモリ１１２０に記憶された命令を実行するように構成されており、図２～図６に対応する方法で第１の集中型コントローラによって実行されるステップを実装する。
プロセッサ１１１０は、メモリ１２０に記憶された命令を実行し、信号を受信するか、又は信号を送信するようにトランシーバ１１３０を制御し、前述の方法における装置によって実行されるステップを完了するように構成されている。メモリ１１２０は、プロセッサ１１１０に統合されていてもよいし、プロセッサ１１１０から独立して配設されてもよい。
一実装では、トランシーバ回路又は専用のトランシーバチップを使用して、トランシーバ・ユニット１１３０の機能が実装されることが考えられてもよく、専用の処理チップ、処理回路、プロセッサ、又は汎用チップを使用して、プロセッサ１１１０が実装されることが考えられてもよい。
別の実装では、この出願のこの実施形態で提供される装置が、汎用コンピュータを使用して実装されることが考えられてもよい。すなわち、プロセッサ１１１０及びトランシーバ１１３０の機能を実装するためのプログラム・コードがメモリ１１２０に記憶され、汎用プロセッサが、メモリ１１２０におけるコードを実行することによってプロセッサ１１１０及びトランシーバ１１３０の機能を実装する。
この出願のこの実施形態で提供される技術的解決策に関連する装置の概念、説明、詳細な説明、他のステップについては、上記の方法又は他の実施例の内容の説明を参照のこと。詳細は、ここでは再度説明されない。
この実施形態の別の形式では、コンピュータ可読記憶媒体が提供される。コンピュータ可読記憶媒体は、命令を記憶する。命令が実行されて、上述の方法の実施実施形態における第１の集中型コントローラによって実行される方法を実行する。
この実施形態の別の形式では、命令を含むコンピュータ・プログラム製品が提供される。命令が実行されて、上述の方法の実施実施形態における第１の集中型コントローラによって実行される方法を実行する。
当業者であれば、記載を容易にするために、図９は、１つのメモリ及び１つのプロセッサのみを示していることを理解してもよい。実際のコントローラでは、複数のプロセッサ及びメモリがあってもよい。メモリはまた、記憶媒体、記憶デバイスなどと呼ばれてもよい。これは、この出願のこの実施形態で限定されない。
この出願のこの実施形態では、プロセッサは、中央処理ユニット（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、略してＣＰＵ）であってもよいことを理解されたい。プロセッサはさらに、別の汎用プロセッサ、デジタル信号プロセッサ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ、略してＤＳＰ）、特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ、略してＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ｆｉｅｌｄ－ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ、略してＦＰＧＡ）、又は別のプログラマブル論理デバイス、ディスクリート・ゲート若しくはトランジスタ論理デバイス、ディスクリート・ハードウェア・コンポーネントなどであってもよい。
さらに、本発明のこの実施形態で言及されているメモリは、揮発性メモリ又は不揮発性メモリであってもよいし、揮発性メモリ及び不揮発性メモリを含んでいてもよいことを理解されたい。不揮発性メモリは、読み出し専用メモリ（ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ、略してＲＯＭ）、プログラマブル読み出し専用メモリ（ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ、略してＰＲＯＭ）、消去可能なプログラマブル読み出し専用メモリ（ｅｒａｓａｂｌｅ ＰＲＯＭ、略してＥＰＲＯＭ）、電気的に消去可能なプログラマブル読み出し専用メモリ（ｅｌｅｃｔｒｉｃａｌｌｙ ＥＰＲＯＭ、略してＥＥＰＲＯＭ）、又はフラッシュ・メモリであってもよい。揮発性メモリは、ランダム・アクセス・メモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ、ＲＡＭ）であってもよく、外部キャッシュとして使用される。限定的な説明ではなく、例えば、多くの形式のＲＡＭが使用されてもよく、例えば、スタティック・ランダム・アクセス・メモリ（ｓｔａｔｉｃ ＲＡＭ、略してＳＲＡＭ）、ダイナミック・ランダム・アクセス・メモリ（ｄｙｎａｍｉｃ ＲＡＭ、略してＤＲＡＭ）、同期ダイナミック・ランダム・アクセス・メモリ（ｓｙｎｃｈｒｏｎｏｕｓ ＤＲＡＭ、略してＳＤＲＡＭ）、ダブル・データ・レート同期ダイナミック・ランダム・アクセス・メモリ（ｄｏｕｂｌｅ ｄａｔａ ｒａｔｅ ＳＤＲＡＭ、略してＤＤＲ ＳＤＲＡＭ）、拡張同期ダイナミック・ランダム・アクセス・メモリ（ｅｎｈａｎｃｅｄ ＳＤＲＡＭ、略してＥＳＤＲＡＭ）、同期ダイナミック・ランダム・アクセス・メモリ（ｓｙｎｃｈｌｉｎｋ ＤＲＡＭ、略してＳＬＤＲＡＭ）、及びダイレクト・ランバス・ランダム・アクセス・メモリ（ｄｉｒｅｃｔ ｒａｍｂｕｓ ＲＡＭ、略してＤＲ ＲＡＭ）である。
プロセッサが、汎用プロセッサ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡ、又は別のプログラマブル論理デバイス、ディスクリート・ゲート若しくはトランジスタ論理デバイス、若しくはディスクリート・ハードウェア・コンポーネントであるときに、メモリ（記憶モジュール）がプロセッサに統合されることに留意されたい。
本明細書で説明されるメモリは、これらのメモリ及び別の適切なタイプの任意のメモリを含むが、これらに限定されないことに留意されたい。
バスは、データ・バスに追加して、電力バス、制御バス、ステータス信号バスなどをさらに含んでもよい。しかしながら、明確に説明するために、図における様々なバスは、バスとしてマーク付けされている。
この明細書における「第１」、「第２」、「第３」、「第４」及び様々な数字は、説明を容易にするための区別のために使用されるにすぎず、この出願の範囲を限定することを意図していないことをさらに理解されたい。
この明細書における「及び／又は」という用語は、関連付けられたオブジェクト間の関連付け関係のみを説明し、３つの関係が存在してもよいことを理解されたい。例えば、Ａ及び／又はＢは、Ａのみが存在し、Ａ及びＢの両方が存在し、Ｂのみが存在するという３つのケースを表してもよい。追加的に、本明細書における文字「／」は通常、関連付けられたオブジェクト間の「又は」関係を示す。
実装プロセスでは、前述の方法におけるステップは、プロセッサ内のハードウェアの統合論理回路を使用して、又はソフトウェアの形態で命令を使用して実装されてもよい。この出願の実施形態を参照して開示された方法のステップは、ハードウェア・プロセッサによって直接的に実行されてもよいし、プロセッサ内のハードウェア及びソフトウェア・モジュールの組み合わせを使用して実行されてもよい。ソフトウェア・モジュールは、ランダム・アクセス・メモリ、フラッシュ・メモリ、読み出し専用メモリ、プログラマブル読み出し専用メモリ、電気的に消去可能なプログラマブル・メモリ、レジスタなど、本技術分野における成熟した記憶媒体内に位置してもよい。記憶媒体は、メモリ内に位置し、プロセッサは、メモリ内の情報を読み出し、プロセッサにおいてハードウェアと組み合わせて前述の方法のステップを完了する。繰り返しを避けるために、詳細は、ここでは再度説明しない。
この出願の実施例で提供される方法によれば、この出願の実施形態は、システムをさらに提供する。システムは、第１の集中型コントローラと、様々なＩ／Ｏデバイスを含み、第２の集中型コントローラなどをさらに含んでもよい。
前述のプロセスのシーケンス番号は、本出願の様々な実施形態における実行シーケンスを意味しない。プロセスの実行シーケンスは、プロセスの機能及び内部論理に基づいて決定されるべきであり、この出願の実施形態の実装プロセスに対するあらゆる限定として解釈されるべきではない。
当業者は、この明細書に開示された実施形態を参照して説明される様々な例示的な論理ブロック（ｉｌｌｕｓｔｒａｔｉｖｅ ｌｏｇｉｃａｌ ｂｌｏｃｋ、略してＩＬＢ）及びステップが、電子ハードウェア又はコンピュータ・ソフトウェアと電子ハードウェアの組み合わせによって実装されてもよいことを認識するであろう。機能がハードウェアによって実行されるのか、コンピュータ・ソフトウェアに実行されるのかは、特定のアプリケーションと技術的解決策の設計上の制約条件に依存する。当業者であれば、特定のアプリケーションごとに、説明された機能を実装するために異なる方法を使用してもよいが、その実装がこの出願の範囲を超えると考えられるべきでない。
この出願で提供されるいくつかの実施形態では、開示されたシステム、装置、及び方法は、他の方式で実装され得ると理解されたい。例えば、説明された装置の実施形態は、一例にすぎない。例えば、ユニットへの分割は、単に論理機能分割であり、実際の実装においては他の分割であってもよい。例えば、複数のユニット又はコンポーネントが別のシステムに組み合わされたり、統合されたりしてもよいし、いくつかの特徴が無視されるか、又は実行されなくてもよい。追加的に、表示又は議論された相互結合、直接結合、又は通信接続は、いくつかのインターフェースを介して実装されてもよい。装置又はユニット間の間接結合又は通信接続は、電子的、機械的、又は他の形態において実装されてもよい。
別々の部分として説明されたユニットは、物理的に別個であってもなくてもよいし、ユニットとして表示されている部分が、物理的ユニットであってもなくてもよいし、１つの位置に位置していてもよいし、複数のネットワーク・ユニットに分散されていてもよい。ユニットの一部又は全部は、実施形態における解決策の目的を達成するために実際の要件に基づいて選択されてもよい。
追加的に、本出願の実施形態における機能ユニットは、１つの処理ユニットに統合されてもよいし、ユニットの各々は、物理的に単独で存在してもよいし、２つ以上のユニットは、１つのユニットに統合される。
前述の実施形態の全部又は一部は、ソフトウェア、ハードウェア、ファームウェア、又はそれらの任意の組み合わせを使用して実装されてもよい。ソフトウェアが前述の実施形態を実装するために使用されるときに、実施形態の全部又は一部は、コンピュータ・プログラム製品の形態で実装されてもよい。コンピュータ・プログラム製品は、１つ以上のコンピュータ命令を含む。コンピュータ・プログラム命令がロードされ、コンピュータ上で実行されるときに、この出願の実施形態による手順又は機能の全部又は部分的に生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータ・ネットワーク、又は他のプログラム可能なデバイスであってもよい。コンピュータ命令は、コンピュータ可読記憶媒体に記憶されてもよいし、１つのコンピュータ可読記憶媒体から別のコンピュータ可読記憶媒体に伝送されてもよい。例えば、コンピュータ命令は、ウェブサイト、コンピュータ、サーバ、又はデータ・センタから、有線（例えば、同軸ケーブル、光ファイバ、又はデジタル加入者線）又は無線（例えば、赤外線、ラジオ、又はマイクロ波）において別のウェブサイト、コンピュータ、サーバ、又はデータ・センタに伝送されてもよい。コンピュータ可読記憶媒体は、コンピュータがアクセス可能な任意の使用可能な媒体、又は１つ以上の使用可能な媒体を統合するデータ記憶デバイス、例えば、サーバ若しくはデータ・センタであってもよい。使用可能な媒体は、磁気媒体（例えば、フロッピー・ディスク、ハード・ディスク、又は磁気テープ）、光媒体（例えば、ＤＶＤ）、又は半導体媒体（例えば、ソリッド・ステート・ドライブ）などである。
前述の説明は、この出願の単に具体的な実装に過ぎないが、この出願の保護範囲を制限することを意図したものではない。この出願に開示された技術的範囲内で、当業者によって容易に理解することができる変更又は代替は、この出願の保護範囲に含まれるものとする。したがって、この出願の保護範囲は、特許請求の範囲の保護範囲に従うものとする。

Claims (14)

  1. Ｉ／Ｏデバイス・アクセス方法であって、
    第１の集中型コントローラによって、車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、前記様々なＩ／Ｏデバイスの標準モデルを生成し、前記様々なＩ／Ｏデバイスと前記標準モデルとの間のマッピング設定ファイルを生成することと、
    ユーザのアクセス動作に基づいてリソース・アクセス要求を生成することであって、前記リソース・アクセス要求は、前記ユーザによってアクセスされる第１のＩ／Ｏデバイスの第１の標準モデルを含む、ことと、
    前記マッピング設定ファイルに基づいて、前記第１のＩ／Ｏデバイスに前記リソース・アクセス要求を送信することと、を含む、方法。
  2. 第１の集中型コントローラによって、車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、前記様々なＩ／Ｏデバイスの標準モデルを生成し、前記様々なＩ／Ｏデバイスと前記標準モデルとの間のマッピング設定ファイルを生成することは、
    前記第１の集中型コントローラによって、アプリケーションによってアクセスされる前記様々なＩ／Ｏデバイスのタイプに基づいて、前記アプリケーションのために前記車両内の前記様々なＩ／Ｏデバイス対してオブジェクト指向モデリングを実行して、前記様々なＩ／Ｏデバイスの前記標準モデルを生成することと、
    前記様々なＩ／Ｏデバイスの物理ポートに基づいて前記Ｉ／Ｏデバイスに対して物理ポート・モデリングを実行することと、前記標準モデルを制御するために使用される標準化データと前記Ｉ／Ｏデバイスを制御するために使用される制御データとの間の変換関係を設定することと、を含む、請求項１に記載の方法。
  3. 前記リソース・アクセス要求は、前記第１の標準モデルを制御するために使用される第１の標準化データをさらに含み、
    前記方法は、
    前記第１の集中型コントローラによって、前記変換関係に基づいて、前記第１の標準化データを前記第１のＩ／Ｏデバイスに対応する第１の制御データに変換することと、
    前記第１の制御データを前記第１のＩ／Ｏデバイスに送信することと、をさらに含む、請求項２に記載の方法。
  4. 前記第１の集中型コントローラによって、前記第１のＩ／Ｏデバイスによって報告されたサンプリング・データを受信することと、
    前記変換関係に基づいて、前記サンプリング・データを前記第１の標準モデルに対応する第２の標準化データに変換することと、をさらに含む、請求項２又は３に記載の方法。
  5. 前記第１の集中型コントローラが第２の集中型コントローラ下にある第２のＩ／Ｏデバイスにアクセスする必要があるときに、前記リソース・アクセス要求は、前記ユーザによってアクセスされる前記第２のＩ／Ｏデバイスの第２の標準モデルを含み、前記方法は、
    前記第１の集中型コントローラによって、前記第１の集中型コントローラと前記第２の集中型コントローラの間の通信層リンクを通して、前記第２のＩ／Ｏデバイスに前記リソース・アクセス要求を送信することをさらに含む、請求項１～４のいずれか一項に記載の方法。
  6. Ｉ／Ｏデバイス・アクセス装置であって、
    車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、前記様々なＩ／Ｏデバイスの標準モデルを生成し、前記様々なＩ／Ｏデバイスと前記標準モデルとの間のマッピング設定ファイルを生成することと、ユーザのアクセス動作に基づいて、リソース・アクセス要求を生成することであって、前記リソース・アクセス要求は、前記ユーザによってアクセスされる第１のＩ／Ｏデバイスの第１の標準モデルを含む、こととを行うように構成された処理ユニットと、
    前記マッピング設定ファイルに基づいて、前記第１のＩ／Ｏデバイスに前記リソース・アクセス要求を送信することを行うように構成されたトランシーバ・ユニットと、を含む、装置。
  7. 前記処理ユニットは、具体的には、
    アプリケーションによってアクセスされる前記様々なＩ／Ｏデバイスのタイプに基づいて、前記アプリケーションのために前記車両内の前記様々なＩ／Ｏデバイス対してオブジェクト指向モデリングを実行して、前記様々なＩ／Ｏデバイスの前記標準モデルを生成することと、
    前記様々なＩ／Ｏデバイスの物理ポートに基づいて前記Ｉ／Ｏデバイスに対して物理ポート・モデリングを実行することと、前記標準モデルを制御するために使用される標準化データと前記Ｉ／Ｏデバイスを制御するために使用される制御データとの間の変換関係を設定することと、を行うように構成されている、請求項６に記載の装置。
  8. 前記リソース・アクセス要求は、前記第１の標準モデルを制御するために使用される第１の標準化データをさらに含み、
    前記処理ユニットは、
    前記変換関係に基づいて、前記第１の標準化データを前記第１のＩ／Ｏデバイスに対応する第１の制御データに変換することを行うようにさらに構成されており、
    前記トランシーバ・ユニットは、前記第１の制御データを前記第１のＩ／Ｏデバイスに送信するようにさらに構成されている、請求項７に記載の装置。
  9. 前記トランシーバ・ユニットは、
    前記第１のＩ／Ｏデバイスによって報告されたサンプリング・データを受信することを行うようにさらに構成されており、
    前記処理ユニットは、前記変換関係に基づいて、前記サンプリング・データを前記第１の標準モデルに対応する第２の標準化データに変換することを行うようにさらに構成されている、請求項７又は８に記載の装置。
  10. 前記装置が第２の集中型コントローラ下にある第２のＩ／Ｏデバイスにアクセスする必要があるときに、前記リソース・アクセス要求は、前記ユーザによってアクセスされる前記第２のＩ／Ｏデバイスの第２の標準モデルを含み、前記トランシーバ・ユニットは、
    前記第１の集中型コントローラと前記第２の集中型コントローラの間の通信層リンクを通して、前記第２のＩ／Ｏデバイスに前記リソース・アクセス要求を送信すること行うようにさらに構成されている、請求項７～９のいずれか一項に記載の装置。
  11. Ｉ／Ｏデバイス・アクセス装置であって、
    車両内の様々なＩ／Ｏデバイスに対してオブジェクト指向モデリングを実行して、前記様々なＩ／Ｏデバイスの標準モデルを生成し、前記様々なＩ／Ｏデバイスと前記標準モデルとの間のマッピング設定ファイルを生成することを行うように構成されたデバイス抽象化層と、
    ユーザのアクセス動作に基づいてリソース・アクセス要求を生成し、前記リソース・アクセス要求を前記デバイス抽象化層に送信するように構成されたアプリケーション層と、を含み、前記リソース・アクセス要求は、前記ユーザによってアクセスされる第１のＩ／Ｏデバイスの第１の標準モデルを含み、
    前記デバイス抽象化層は、通信層に前記リソース・アクセス要求を送信するようにさらに構成されており、
    前記通信層は、前記Ｉ／Ｏデバイスに対する入力／出力動作を実行するために、前記リソース・アクセス要求に基づいて、トランシーバを使用して制御コマンドをドライバ層に送信するように構成されている、装置。
  12. 前記ドライバ層は、前記制御コマンドに応答して、前記入力／出力動作を通して取得されたサンプリング・データを前記通信層に送信するように構成されており、
    前記通信層は、前記サンプリング・データを前記デバイス抽象化層に送信するようにさらに構成されており、
    前記デバイス抽象化層は、前記サンプリング・データを前記標準モデルに対応する標準化データに変換し、前記標準化データを前記アプリケーション層に送信するようにさらに構成されている、請求項１１に記載の装置。
  13. Ｉ／Ｏデバイス・アクセス装置であって、
    プロセッサと、メモリと、バスと、を含み、前記プロセッサ及び前記メモリは、前記バスを使用して接続され、前記メモリは、プログラム・コードのグループを記憶するように構成されており、前記プロセッサは、前記メモリに記憶された前記プログラム・コードを呼び出して、請求項１～６のいずれか一項による方法を実行する、装置。
  14. コンピュータ可読記憶媒体であって、
    前記コンピュータ可読記憶媒体は、命令を記憶し、前記命令がコンピュータ上で実行されるときに、請求項１～６のいずれか一項に記載の方法が実装される、コンピュータ可読記憶媒体。
JP2023530559A 2020-11-20 2020-11-20 Ｉ／ｏデバイス・アクセス方法及び装置 Pending JP2023550936A (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/130639 WO2022104747A1 (zh) 2020-11-20 2020-11-20 一种访问io设备的方法及装置

Publications (1)

Publication Number Publication Date
JP2023550936A true JP2023550936A (ja) 2023-12-06

Family

ID=75034941

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2023530559A Pending JP2023550936A (ja) 2020-11-20 2020-11-20 Ｉ／ｏデバイス・アクセス方法及び装置

Country Status (5)

Country Link
US (1) US20230291604A1 (ja)
EP (1) EP4238832A4 (ja)
JP (1) JP2023550936A (ja)
CN (2) CN112566819B (ja)
WO (1) WO2022104747A1 (ja)

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6434459B2 (en) * 1996-12-16 2002-08-13 Microsoft Corporation Automobile information system
DE10015114A1 (de) * 2000-03-28 2001-10-04 Bosch Gmbh Robert Verfahren und Vorrichtung zur Modellierung eines mechatronischen Systems in einem Kraftfahrzeug
KR100611098B1 (ko) * 2003-12-12 2006-08-09 한국전자통신연구원 인터페이스 표준 모델을 이용한 위성 시뮬레이션 모델링시스템
CN100399274C (zh) * 2005-09-19 2008-07-02 联想(北京)有限公司 一种虚拟机系统输入/输出设备动态分配的方法及其设备
US8838332B2 (en) * 2009-10-15 2014-09-16 Airbiquity Inc. Centralized management of motor vehicle software applications and services
CN102136933B (zh) * 2010-09-30 2013-08-28 华为技术有限公司 设备管理方法、中间件及机器通信平台、设备和系统
US8955037B2 (en) * 2011-05-11 2015-02-10 Oracle International Corporation Access management architecture
US9218195B2 (en) * 2011-05-17 2015-12-22 International Business Machines Corporation Vendor-independent resource configuration interface for self-virtualizing input/output device
CN103150152A (zh) * 2011-12-06 2013-06-12 广东新岸线计算机系统芯片有限公司 一种移动终端的外设电源管理方法和系统
CN105610904B (zh) * 2015-12-17 2018-12-18 四川物联亿达科技有限公司 一种统一接入设备的接入服务系统
CN107229584B (zh) * 2017-06-01 2020-03-13 西南电子技术研究所（中国电子科技集团公司第十研究所） 航空电子仿真测试平台i/o管理系统
US10732634B2 (en) * 2017-07-03 2020-08-04 Baidu Us Llc Centralized scheduling system using event loop for operating autonomous driving vehicles
CN109474912B (zh) * 2018-04-10 2022-02-18 西南大学 一种车载网关系统以及车载子系统的监控方法和装置
CN108770016B (zh) * 2018-06-04 2019-07-05 北京邮电大学 基于模板的5g端到端网络切片生成方法及装置
CN111787049A (zh) * 2020-05-09 2020-10-16 苏州中科中霖电子科技有限公司 一种基于设备对象的物联网设备管理方法与系统
CN111949037A (zh) * 2020-08-26 2020-11-17 北京享云智汇科技有限公司 一种网联车自动驾驶系统及方法

Also Published As

Publication number Publication date
WO2022104747A1 (zh) 2022-05-27
EP4238832A4 (en) 2023-12-06
EP4238832A1 (en) 2023-09-06
CN112566819B (zh) 2022-09-16
US20230291604A1 (en) 2023-09-14
CN112566819A (zh) 2021-03-26
CN115489459A (zh) 2022-12-20

Similar Documents

Publication Publication Date Title
JP7244657B2 (ja) 車載ゲートウェイ通信方法、車載ゲートウェイ、及びインテリジェント車両
EP2541846B1 (en) Communication method of gateway device supporting CAN - and Modbus protocol conversion and gateway device using the same
EP4202645A1 (en) Vehicle upgrading method and apparatus
KR20100015510A (ko) 차량의 통신 시스템 및 통신 시스템 작동 방법
WO2021047254A1 (zh) 实现汽车中电子控制功能的系统、方法以及汽车
EP4024792A1 (en) Packet forwarding method, apparatus, system, and device, and storage medium
KR20200143961A (ko) 차량 진단 통신 장치, 그를 포함한 시스템 및 그 방법
CN113141306A (zh) 一种诊断报文路由方法及其总线路由设备
Jiang Vehicle e/e architecture and its adaptation to new technical trends
CN110497920A (zh) 信号处理方法、装置及系统
US20230066378A1 (en) System and method for implementing automobile electronic control function
JP2024512364A (ja) Ｕｗｂモジュールの車両内自動位置特定
JP2023550936A (ja) Ｉ／ｏデバイス・アクセス方法及び装置
US20210291763A1 (en) System and Method for Implementing Automobile Electronic Control Function
CN105491082B (zh) 远程资源访问方法和交换设备
US10541834B2 (en) Apparatus and method of controlling operation of slave controller
EP3457667B1 (en) Method, control device and agent device for operation of equipment
CN109542833A (zh) 一种基于微服务器架构的服务器管理方法、装置、服务器
CN105553452B (zh) 用于与功率开关器件进行通信的方法和设备
EP4350511A1 (en) Method and apparatus for co-simulation
US20220276856A1 (en) Software upgrading method, apparatus, and system
CN115730395B (zh) 汽车接口模型生成方法、装置、计算机设备和存储介质
CN115914429B (zh) 通信协议适配方法、装置、电子设备、车辆及存储介质
CN117336113A (zh) 车辆控制系统的通信方法及相关装置
CN114338272A (zh) 通信控制方法、装置、车辆及可读存储介质

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230628

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230628