3
周辺機器
3.1 IOハードウェアの抽象化
IO ハードウェア抽象化は、ECU 抽象化レイヤーの一部です。IO ハードウェア抽象化モジュールの目標は、RTE を介してデータを送信できるようにすることです。
ECUハードウェアに依存せずに出力します。これは、ソフトウェア コンポーネントの設計者が信号がどのような影響を与えるかについて詳しく知る必要がないことを意味します。
物理層に影響を与えます。したがって、このモジュールは ECU 固有です。
これは主に、ECU 信号を IO 抽象ポートにマッピングすることによって実現されます。モジュール IO ハードウェア抽象化は、初期のために提供されます。
IO ハードウェア抽象化全体を初期化するモジュール。
以下の図は、IO ハードウェア抽象化ブロックを示しています。これは MCAL ドライバーの上にあります。つまり、IO ハードウェア抽象化モジュールを調整する必要があります。
オンチップデバイスはドライバー API を使用して管理されます。MCAL ドライバーの構成は、IO ハードウェア抽象化モジュールによって提供される ECU によって異なります。
信号の品質。たとえば、関連する変化がピン層で発生した場合 (立ち上がりエッジ、立ち下がりエッジ)、通知が必要です。システム
設計者は、特定の信号の通知を許可するように MCAL ドライバーを構成する必要があります。通知はドライバーから送信され、IO ハードで送信されます。
それはピース抽象モジュールで処理されます。
3.2 ADCドライバー
ADC ドライバーは、マイクロコントローラー内のアナログ - デジタル変換ユニットを初期化し、制御します。ドライバーには一連の基本機能が含まれています
関数。一部の特殊なアプリケーションで信号の周波数解析 (高速フーリエ変換など) を実行できるようにするには、次のことが必要です。
ストリーミングアクセスの機能を強化する必要がある。
ADC ドライバーは次のサービスを提供します。
·
信号値結果のアクセスモード
·
ストリーミングアクセス。
通常、ADC チャネルの変換要求は、ADC チャネル グループを通じて制御されます。チャンネルグループは連続可変で動作可能
スイッチングモードまたはワンショットスイッチングモード。
変換処理と対話: 同時に、ADC ドライバーは、異なる変換モード用に構成された複数のグループを管理します。
変換プロセス:
通常、ADC チャネルの変換要求は、ADC チャネル グループを通じて制御されます。グループで連続ターン走行可能
変換モードまたはワンショット変換モード。ワンショット変換モードのトリガー条件も設定および制御されます。
チャネルが異なるモードで動作している場合 (たとえば、連続スイッチング モードによる通常動作では、ある時点で)
ワンショットまたはコマンドベースの変換を使用した特殊な変換の場合、チャネルを次のように割り当てる必要があります。
複数のグループの。
グループ間で共有されるチャネルの動作モードを変更するには、アプリケーションは、指定されたチャネルを含むグループへの現在のアクセスを停止する必要があります。
前に変換してから、指定したチャンネルを含む新しいグループの変換を開始します。
アプリケーションがいつでも即時変換を実行できるように、オンコマンド変換が定義されています。それ
グループ移行を一時停止し、コマンドによる移行アクティビティが完了した後に再アクティブ化する必要があります。
3.3 DIOドライバ
DIO ドライバーは、ポートおよびチャネルベースの内部汎用 I/O ブレークポイントへの読み取りおよび書き込みアクセスを提供します。ここで読み書きし、
バッファリングされません。このドライバーの基本的な動作は同期です。
DIO ドライバーは、次の機能への読み取りおよび書き込みのためのサービスを提供します。
·
DIOチャンネル(ピン)
·
DIOポート
·
DIOチャンネルグループ
これらのサービスの動作は同期的です。モジュールはピンとポートで動作し、PORT ドライバーによって構成されます。
したがって、ポート構造は DIO ドライバーで構成および初期化されません。
ポートドライバーモジュール:
多くのポートとポート ピンは、ポート ドライバー モジュールによってさまざまな機能に割り当てられます。
·
常规 I/O
·
ADC
·
SPI
·
PWM
DIO ドライバーは、マイクロコントローラーのハードウェア ピンへのアクセスを抽象化します。さらに、これらのピンをグループ化することもできます。
DIO ドライバーは次のサービスを提供します。
·
ポートまたはチャンネルグループの出力チャンネルのレベルを 1 つずつ変更します。
·
ポートまたはチャネルグループの入力および出力チャネルのランクを 1 つずつ読み取ります。
DIO ドライバーのすべての読み取りおよび書き込みサービスは再入可能である必要があります。その理由は、これらの DIO ドライバーはさまざまなデバイスで使用できるためです。
レイヤーハンドラーまたはドライバーへのアクセス。これらの上位モジュールはドライバーに並行してアクセスできます。
3.4 GPTドライバー
GPT ドライバーでは、ワンショットまたは永続的なタイマー通知が可能です。このモジュールは汎用タイマーのハードウェア タイミング パスを使用します
道路、つまりオペレーティング システムまたはその他の基本ソフトウェア モジュール用 (このようなモジュールでは、OS 警告サービスの開発が多すぎます)
ピン）は、正確な短期間のタイミングを提供します。
GPT ドライバーは、ハードウェア タイミング モジュール内の関数タイミング インスタンス (チャネル) を開始および停止するためのサービスを提供します。できる
単一のタイムアウト期間だけでなく、繰り返しのタイムアウト期間も生成できます。通知を呼び出す必要がある場合、要求されたタイムアウト期間が経過したとき
有効期限が切れると、ユーザーは設定できるようになります。通知は実行時に有効または無効にすることができます。
前回の通知が発生してからの相対的な経過時間、または次の通知までの残り時間のクエリを実行できます。
GPT ドライバーはタイムベースを生成するだけであり、タイムカウンターは提供しないことに注意してください。この機能は別のモジュールによって提供されます
（ICUドライバー）。
GPT ドライバーを使用すると、事前定義されたタイムアウト期間の満了に関係なく、ECU をウェイクアップできます。スキーマ切り替えサービスは GPT を変換します
ドライバーは通常動作とスリープ モードの間で移行します。
ドライバは、クロック ソース、プリスケーラ、および監視レジスタによって制限されるタイムアウト期間を提供しません。
最大値。ユーザーはこれに注意する必要があります。
3.5 ICUドライバー
ICU ドライバーは、マイクロコントローラーのインプット キャプチャ ユニットを制御します。次の機能を提供します。
·
定期的なローエンド、ハイエンドの時間測定
·
エッジの検出と通知
·
エッジ数
·
エッジタイムスタンプ
·
ウェイクアップ割り込み
信号のエッジ検出にはキャプチャコンペアユニットのエッジ検出器または外部時間の割り込み制御を使用する必要があります。
デバイス。
信号測定には、キャプチャ タイマーと少なくとも 1 つのキャプチャ レジスタが必要です。
ICU は PWM 信号を変調し、パルスをカウントし、周波数とデューティ期間を測定し、単純な割り込みを生成し、
ウェイクアップ割り込み。
ICU ドライバーは次のサービスを提供します。
·
シグナルエッジ通知
·
ウェイクアップ割り込みの制御
·
定期的な信号時間の測定
·
非周期信号の取得に使用できるエッジ タイムスタンプ
·
エッジ数
データの一貫性を確保するには、再入可能なコードを提供する必要があります。
時間単位の拍子
レジスタ値から時間を取得するには、発振器周波数、プリスケーラなどを知る必要があります。これらの設定は
MCU モジュールまたは他のモジュールで生成されるため、これらの時間を計算することはできません。したがって、時間と拍の間の変換は次のようになります。
責任は上層部にある。
3.6 MCUドライバー
MCU ドライバーは、基本的なマイクロコントローラーの初期化、パワーダウン、リセット、その他の MCAL ソフトウェア モジュールのニーズを提供します。
マイクロコントローラー固有の機能のためのサービス。初期化サービスは柔軟性を提供し、スタートアップ コードに加えて、
アプリケーション関連の MCU 初期化。スタートアップ コードは完全に MCU 固有です。MCUドライバがマイコンに直接アクセス
コントローラー ハードウェア。マイクロコントローラー抽象化レイヤー (MCAL) に存在します。
MCUドライバーの特徴:
·
MCU クロック、PLL、クロック プリスケーラー、MCU クロック分配の初期化
·
RAMコンポーネントの初期化
·
マイクロコントローラーの省電力モードを有効にする
·
マイクロコントローラーのリセットを有効にする
また、ハードウェアからリセットするサービスを提供するのには理由があります。
MCU はマイクロクロックと RAM の初期化を駆動して MCU サービスを提供します。MCU 構成セットでは、MCU 固有の
クロック (PLL 設定など) と RAM (セグメントのベース アドレスやサイズなど) を設定する必要があります。
3.7ポートドライバー
このモジュールは、マイクロコントローラーのポート構造全体を初期化します。多くのポートとポートピンをさまざまな機能に割り当てることができます
たとえば、次のことができます。
·
通用 I/O
·
ADC
·
SPI
·
SCI
·
PWM
このため、このポート構造の一般的な設定と初期化を実行する必要があります。これらのポートピンの構成と使用方法
使用方法はマイコンとECUに依存します。
このモジュールは、マイクロコントローラーのポート構造全体を初期化するためのサービスを提供する必要があります。多くのポートとポート ピンを使用できます。
さまざまな機能が割り当てられています。このため、ポート構造の完全な構成と初期化が必要です。これらの端
ポートピンの構成とモードは、マイクロコントローラーと ECU に依存します。
ポート ドライバー モジュールは、DIO ドライバーで使用されるポート構造のすべての構成と初期化を完了する必要があります。
モジュール内で。したがって、DIO ドライバーはピンとポート上で動作し、それを構成するのはポートドライバー次第です。ポートとポート
ピンの構成順序は構成ツールの責任です。
DIO 機能を使用する前に、ポートドライバーを初期化する必要があります。そうしないと、DIO ドライバーは未定義の動作を生成します。
ポートアクセスの原子性: ポートドライバーが提供する必要があります
ポートへのアトミック アクセスを提供します。
3.8 PWMドライバー
各 PWM チャネルは、マイクロコントローラーに属するハードウェア PWM に接続されます。ドライバーは初期化と制御を提供します
マイクロプロセッサ内の PWM サービス。PWM モジュールは、異なるパルス幅のパルスを生成します。
3.9 SPIハンドラー/ドライバー
SPI バスはマスター/スレーブのマルチノード バス システムであり、マスター ノードはチップ セレクト (CS) を設定して、SPI バスのスレーブ ノードを選択します。
データ通信。SPI には 4 線式同期シリアル インターフェイスがあります。チップセレクトラインを使用してデータ通信をアクティブにします。
次の SPI モジュールは、SPI バス上のさまざまなデバイスへのチャネルベースの読み取り、書き込み、および転送アクセスを提供します。SPI通信
道路はデータ要素を表します (
8 ～ 16 ビット）。これらのチャネルは連続して組み合わせることができ、中断することはできません。チャネルには、ボーレート、チップセレクトなどを定義する静的な構成があります。SPI デバイスは通常、使用される SPI ハードウェア ユニットと関連するチップ選択ラインで構成されます。
特定する。このモジュールは SPI マスター ノードとして使用できます。
このソフトウェア モジュールの機能範囲は、各 ECU のタイミング ニーズにできる限り適応できるように静的に構成できる必要があります。
欲しい。つまり、同期、非同期、またはその両方などの SPI アクセスが ECU に存在する可能性があります。したがって、
2 つの SPI ドライバーが存在できますが、インターフェイスを処理するのは 1 つだけです。
SPI ハンドラー/ドライバーは、SPI バス経由で接続されたデバイスに読み取りおよび書き込みを行うサービスを提供します。それは提供します
オンチップ SPI ペリフェラルを構成するために必要なメカニズム。
モノリシック SPI ハンドラー/ドライバーには、処理機能とドライバー機能の両方が含まれています。その主な目標は、各マイクロコントローラーを最大限に活用することです。
コントローラーの特性により、静的構成の最適化に依存して、ECU のニーズに可能な限り適応することが可能になります。
3.10ウォッチドッグインターフェイス
内部ウォッチドッグ ドライバーは、MCU の内部ウォッチドッグ タイマーを制御します。トリガー機能とモード選択サービスを提供します。
外部ウォッチドッグドライバー
外部ウォッチドッグ ドライバーは、外部ハードウェア ウォッチドッグを制御します。トリガー機能とモード選択サービスを提供します。それは持っています、そしてその中に
機能範囲はウォッチドッグドライバと同じです。
1 つの ECU で複数のウォッチドッグ デバイスとウォッチドッグ ドライバーが使用されている場合 (たとえば、内部ソフトウェア ウォッチドッグ
ウォッチドッグおよび外部ハードウェア ウォッチドッグ）、このモジュールにより、ウォッチドッグ マネージャーは適切なウォッチドッグ ドライバーを選択し、
ウォッチドッグデバイス。
ウォッチドッグ ドライバー インターフェイスは、モード遷移やトリガーなど、基礎となるウォッチドッグ ドライバーのサービスへの均一なアクセスを提供します。もつ
デバイス インデックスにより、適切なウォッチドッグ デバイスが選択されます。ウォッチドッグ駆動サービスの動作 (同期/非同期/タイミング) は保護されます。
ウォッチドッグ ドライバー インターフェイスは、ウォッチドッグ ドライバーに機能を追加しません。ウォッチドッグ ドライバー インターフェイスもウォッチドッグに従属していません。
トグルモードやウィンドウモード、タイムアウト期間などの本質的な抽象化。つまり、ドライバーインターフェイスは基礎となるレイヤーを隠蔽しません。
ウォッチドッグ ドライバーとウォッチドッグ デバイスの機能。
4
AUTOSAR の手法、モデル、ツール、適合性テスト
4.1 AUTOSAR手法
AUTOSAR では、システム開発の特定のステップで共通の技術的アプローチが必要です。この方式を「AUTOSAR方式」といいます。
「AUTOSAR メソッド」は完全なプロセス記述でもビジネス モデルでもありません。また、このメソッドでは「角度」が定義されていません。
AUTOSAR のアプローチは単に「役割」と「責任」であり、どのアクティビティを実行するかを規定するものではありません。
作業成果物フローは、作業成果物フロー内のアクティビティの相互依存関係を定義します。
AUTOSAR アプローチでは、全体的なタイムラインは定義されず、反復がいつどのように実行されるかも定義されません。例えば部署内で
システム設計では、同じ動作 (つまり、システム構成の動作) がさまざまな精度で繰り返されます。最初の「ラフ」
構成と最後の「正確な」構成は、実際の構成、さらには ECU の実装によって異なります。
上図は、AUTOSAR手法を使用してECUを設計から構築、統合まで記述するプロセスを示しています。
1. まず、システム構成入力を定義し、ソフトウェアおよびハードウェア コンポーネントを選択し、システム全体の制限を特定します。
これはシステム設計またはアーキテクチャのタスクです。AUTOSAR は、情報交換フォーマット (ソフトウェア コンポーネント、
ECU リソース、システム制約) およびテンプレートを使用して、これらの最初のシステム設計決定の正式な説明を削減します。それで設定しました
システム構成入力を定義するということは、適切なテンプレートを入力して編集することを意味します。テンプレートを最初から記入する
または、ユースケースに応じて、テンプレートを再利用します (いくつかの変更が必要になる場合もあります)。基本的に、AUTOSAR アプローチでは次のことが可能になります。
テンプレートの再利用性が高い。
2. 「システムの構成」アクティビティでは、主にリソースとタイミングの要件に関してソフトウェア コンポーネントを ECU にマッピングします。
3. 「システムの構成」の出力は「システム構成の説明」です。この説明にはすべてが含まれます
システム情報 (バス マッピング、トポロジなど) と、ソフトウェア コンポーネントがどの ECU に配置されているかのマッピングがあります。
4. Extract ECU-Specific Information アクティビティは、システム構成の説明から抽出されます。
特定の ECU に必要な情報を取得します。
5. 次に、システム構成の ECU 抽出に出力します。
6. アクティビティ「ECU の構成」では、タスクのスケジューリング、必要な BSW (ベース) など、実装に必要なすべての情報を追加します。
基本ソフトウェア) モジュール、BSW の構成、タスク内の実行可能エンティティの割り当てなど。
7. アクティブな ECU 設定の結果は、受信を担当する ECU 設定説明に出力されます。
特定の ECU に関するすべてのローカル情報を収集します。この情報から、その特定の ECU 用の実行可能ファイルを構築できます。
ソフトウェア。
8. 最後のステップでは、ECU 構成の説明に従ってアクティビティを生成します。
で取得した情報から実行可能なソフトウェアが生成されます。通常、このステップにはコードの生成が含まれます (RTE や BSW など)。
コードに変換する)、コードをコンパイルする (成長したコードをコンパイルするか、ソフトウェア コンポーネントのソース コードをコンパイルする)、コンパイルされたすべてのコードを変換する
コードは実行可能ソフトウェアに連結されます。
9. 実行可能な ECU ソフトウェアを入手します。
AUTOSAR アプローチの簡単な紹介では、ソフトウェア コンポーネントをシステム全体に統合する必要もあります。
たとえば、コンポーネント API の生成、コンポーネント関数の実装などです。これらは上の図には示されていませんが、ソフトウェア コンポーネントの実装は
現在では、ECU の構成からはほぼ独立しています。
4.2 AUTOSARモデル
4.2.1起源
AUTOSAR を使用すると、組み込みコントローラと対応するソフトウェア実行ユニットで構成される分散システムのあらゆる側面を正確かつ形式的に記述でき、非常に柔軟でありながら安定した信頼性の高いソフトウェア エンジニアリング ライフ サイクルを確立できます。
この説明は、ソフトウェア コンポーネントの高レベルのインターフェイス要件から、特定のバス メッセージの下位レベルのバイト制限まで多岐にわたります。
システム。さまざまな記述から取得する必要がある情報は、AUTOSAR のさまざまなワーク パッケージによって決まります。そして、これらの説明は、
AUTOSARモデル。
AUTOSAR モデルは、UML2.0 メタモデルを簡略化した UML2.0 のサブセットに属します。UML2だから
高度にモジュール化された構造と、クラス、属性、および関連付けの再定義の過剰な使用により、特定の内容を示すために 1 つまたは 2 つの図を使用することが困難になる場合があります。
明確な読みやすさを維持しながら、特定の側面を示します。したがって、ここでは UML2.0 メタモデルを簡略化し、いくつかの要素のみを含めます。
4.2.2用語
4.2.3メタモデルシステム
以下の図に示すように、完全な AUTOSAR テンプレート メタモデル システムには 5 つの層があります。
M0層：AUTOSARオブジェクト
これは AUTOSAR システムの実装です。実際の ECU は、ワイパー制御ソフトウェアを含むソフトウェア イメージを実行します。
M1層: AUTOSARモデルこのメタレベル モデルは、AUTOSAR エンド ユーザー (自動車エンジニア) によって構築されます。彼らは「雨」と定義した
「ブラシ」ソフトウェア コンポーネントと他のソフトウェア コンポーネントへの一連のインターフェイスなど。このレベルでは、AUTOSAR システムはさらに細分化されます。
再利用可能なコンポーネントと特定のインスタンスに分割します。
M2層: AUTOSARメタモデル
この層は、後で AUTOSAR エンド ユーザーによって使用される「語彙」を定義します。たとえば、この層は
AUTOSAR には、「ソフトウェア コンポーネント」という名前のエンティティと「ポート」という名前の別のエンティティがあります。これらの実体の間で
リンケージとセマンティクスは両方ともモデル全体の一部です。
M3 : AUTOSARテンプレートのUML プロファイル
M2 レイヤーのテンプレートは、M3 レイヤーによって定義されたメタモデルから構築されます。前に説明したように、これは UML に加えて
テンプレートのモデリング作業をより適切にサポートするための特定の UML プロファイル。厳密に言えば、M2 層のテンプレートは依然として UML です
インスタンスを使用しますが、テンプレート プロファイルも使用します。
M4 : メタオブジェクト機能
概念を完全にするために、OMG は MOF を最後のメタ層に配置します。MOF は反抗的なものとして定義されているため、
単射的なため、それ以上のメタレイヤーは必要ありません。
4.3 AUTOSARツール
「AUTOSAR オーサリング ツール」とは、すべての AUTOSAR を意味します
XML 記述用ツール (AUTOSAR モデルの XML 表現)。これらのモデルは、次のテンプレートから生成されます。
1. ソフトウェアコンポーネントテンプレート、
2. ECUリソーステンプレート、
3. AUTOSAR システム テンプレート。
AUTOSAR オーサリング ツールは、次の図に示すように、いくつかの重要な側面で構成されています。
オーサリングツールの機能定義
「オーサリング ツールの特性定義」では、AUTOSAR 全体の概念のうち、交換記述に関する部分の段階的な実装を提案しています。
つまり、ソフトウェア コンポーネント テンプレート、ECU リソース テンプレート、およびシステム テンプレートです。最初の実装に基づいて、AUTOSAR を定義します
テンプレートのサブセット用の AUTOSAR オーサリング ツール。Bオーサリングツールの共同作業
「オーサリング ツールのコラボレーション」では、異なるツール間で AUTOSAR モデルを交換するときに発生する可能性のある問題に焦点を当てています。
問題。このドキュメントでは、まずデータ交換のいくつかの基本概念を説明し、次にこれらの問題を解決する戦略の概要を簡単に説明します。
少し。
C行動モデルの相互作用
「動作モデルの相互作用」には、AUTOSAR の動作モデルの使用例がリストされています。そして行動モデルを特定する
AUTOSAR メタモデルの一部。
Dグラフィック記号
グラフィック シンボルでは、AUTOSAR オーサリング ツールの AUTOSAR グラフィック シンボルを定義します。たとえば、ドキュメントがグラフィックであるとします。
CompositionType のモデリングは、包括的なスキーマを提供します。これらのグラフィック シンボルは、AUTOSAR オーサリングの実装として使用する必要があります。
ツールガイド。
4.4適合性テスト
AUTOSAR 適合性テストの目的は、製品が AUTOSAR 仕様に準拠しているかどうかを検証することです。これらの製品
製品は、相互運用性、再利用性/移植性、拡張性の観点から AUTOSAR 標準への準拠を実証する必要があります。
AUTOSAR はオープン標準であるため、すべての最終仕様は標準の一部です。
このドキュメントでは、特定の製品の AUTOSAR 準拠を実証するために必要な、相互に関連するいくつかのパスに焦点を当てます。テストされた
プロセスの複雑さはできる限り低くする必要がありますが、サプライヤーと顧客の関係に応じて最適なテストを決定する必要があります。
プラン。
適合性テストにおける役割は次のとおりです。
（1）
AUTOSAR (標準を維持し、AUTOSAR 仕様の使用を監視します)、
（2）
適合性テスト機関（ファーストパーティCTAとサードパーティCTAに分かれ、主な業務）
テスト パッケージの提供、テストの実行、サポートおよび認定サービスの提供を目的としています)、
（3）
製品サプライヤー (製品の開発およびテスト)
5
要約する
AUTOSAR の提案は、次のような側面から車載電子ソフトウェアの開発に大きな影響を与えています。
外：
（1）
OEM への影響
AUTOSAR の導入は OEM にとって最も有益です。ソフトウェアの調達と管理をより柔軟に行えるようにする
より大きな権利を得ることで、ソフトウェアプロバイダーは徐々に増加し、より多くの選択肢が与えられると同時に、ソフトウェアシステムのオープン性も高まります。
その結果、ソフトウェアの品質監視もそれに応じて向上します。これらは間違いなく彼らにとって有益であり、無害です。
（2）
部品サプライヤーへの影響
コンポーネントの提供への影響は 2 つの観点から分析する必要があります。技術的な観点から見ると、ソフトウェア技術の発展はコンポーネントに大きな影響を与えます。
プロバイダーがもたらす効率の向上には疑いの余地がありません。ソフトウェアの移植性、可用性、保守性などが強化され、
ソフトウェア開発者にとってのメリットは非常に大きいです。
商業的な観点から見ると、オープン ソフトウェア標準の提案はすべてのソフトウェア プロバイダーにとって有益です。しかし同時に理論は
一般的に言えば、一部のソフトウェアプロバイダーによる以前の独占モードは、このオープンシステムの提案によって打破されました。新しい市場が開かれます
オープン、競争、機会が共存します。従来のコンポーネントプロバイダーは、そのベース構築により依然として市場で優位性を持っていますが、新しいプロバイダー
企業にはこれまでよりも多くのチャンスが与えられるでしょう。
（3）
チッププロバイダーへの影響
チッププロバイダーへの影響は一般的であり、主にサポート作業を提供するためです。基本的なソフトウェアの開発がまだ必要なため、
チッププロバイダーの強力なサポートが必要であるため、チッププロバイダーはこの規格のサポートを提供するためにあらゆる努力を惜しみません。非核ではあるが
本業だが、サポートを完全に手放した場合、市場シェアに少なからず影響が出る可能性がある。