パワーウィンドウ

自動車は、次のような制御操作にエレクトロニクスを使用しています。

ウィンドウおよびサンルーフの開閉
ミラーおよびヘッドライトの調節
ドアのロックおよびロック解除

これらのシステムは、厳しい動作制約を受けています。故障により、危険な状況、場合によっては生命に関わる状況が発生する可能性があります。結果として、展開前に慎重な設計と解析が必要です。

この例では、自動車のパワーウィンドウシステム、特に助手席のウィンドウの設計に注目します。このシステムの重要な側面は、ウィンドウを閉めるときに物体に対して 100 N を超える力を及ぼすことができないことです。このような物体が検出されると、ウィンドウは約 10 cm 下がらなければなりません。

設計プロセスの一環として、この例では以下を検討します。

タイミングの要件や力の要件などの、ウィンドウ制御システムの量的要件
アクティビティ図で記述するシステム要件
アクティビティ図で使用する信号のデータ定義

この例で示す設計プロセスのその他の要素は次のとおりです。

システムのコンポーネントの管理
モデルの作成
システムシミュレーションの結果の検証
コードの生成

MATLAB^® および Simulink^® は、初期仕様からコード生成までの組み込み制御設計のためのモデルベースデザインをサポートします。パワーウィンドウコントロールプロジェクトでは、MathWorks^® ツールとモデルベースデザインプロセスを使用して、自動車のパワーウィンドウシステムの構想から実装に至る方法を示します。これはファイルやその他のモデルコンポーネントの整理にプロジェクトを使用します。

パワーウィンドウコントロールプロジェクト

この例では、プロジェクトを使用して自動車のパワーウィンドウシステムをモデル化する方法を示します。このプロジェクトでは、モデルベースデザインと次のような大規模モデリングの手法を使用します。

Model ブロックにより、階層を別々のモデルに分離します。
Variant Subsystem ブロックにより、さまざまな設計の選択肢をモデル化して切り替えます。
ライブラリにより、Variant Subsystem で再利用するためのアルゴリズムを取得します。
プロジェクトにより、システム開発に必要なファイルを管理します。

設計要件

この例では、自動車の助手席のパワーウィンドウシステムについて考えます。このシステムでは、ウィンドウを閉めるときに物体に対して 100 N を超える力を及ぼすことができません。

このような物体が検出されると、モデルによってウィンドウは約 10 cm 下げられなければなりません。

設計要件の詳細については、パワーウィンドウを参照してください。

プロジェクトの確認

プロジェクトを目視すると、この例の整理に使用されている機能を確認できます。以下の機能はプロジェクトの整理に使用されます。

フォルダー
ファイルの分類
ショートカット

フォルダー

プロジェクトは以下のフォルダーに整理されています。

configureModel - メインシステムモデルのバリアントコンフィギュレーションを制御する MATLAB® ファイル
data - プロジェクトに必要なイメージ
hmi - パワーウィンドウの応答をアニメーション化するファイル
model - メインシステムモデル、コントローラーモデル、コントローラーをテストするためのモデル、これらのモデルをサポートするライブラリ
task - さまざまなモデルコンフィギュレーションでのモデルのシミュレーションや、コントローラーのカバレッジレポートの生成を行う MATLAB ファイル
utilities - モデルの初期化、スプレッドシート入力の生成、生成されたスプレッドシートへのデータの追加、起動時と終了時のプロジェクト環境の管理を行うための MATLAB ファイル

ファイルの分類

[ラベル] ペインに、プロジェクトのファイルのさまざまな分類が表示されています。各ラベルは、ファイルがプロジェクトの本体に対して果たす具体的な役割を示しています。

Configuration - プロジェクトまたはモデルを設定するファイル。
PrjConfig - ファイルを起動時にパスに追加して終了時に削除することでプロジェクトを設定するファイル
DesignConfig - 特定の時点でどのモデルコンフィギュレーションをアクティブにするかを決定するファイル
Design - メインシステムモデルとその参照先の制御モデル
DesignSupport - ライブラリ、データ、モデルシミュレーションなどのファイル
Simulation - 特定のコンフィギュレーションでモデルのシミュレーションを実行するファイル
Test - コントロールカバレッジ、コントロール相互作用、テストハーネスのモデル
Visualization - パワーウィンドウの動きをアニメーション化するファイル

ショートカット

プロジェクトのショートカットにより、最もよく使用するプロジェクトファイルに簡単にアクセスできます。ショートカットの中には、プロジェクトを起動時にパスに追加して終了時に削除するなどの一般的なタスクが含まれるものもあります。また、プロジェクトのショートカットグループを使用するとショートカットの整理に役立ちます。

Interactive Testing - コントローラーの対話型テストに使用するファイル
Main Model - 最上位レベルの Simulink モデルのファイル
Model Coverage - コントローラーのモデルカバレッジに使用するファイル
Simulation - モデルのバリアントコンフィギュレーションのシミュレーションに使用するファイル

プロジェクト内の Simulink モデルの調査

このプロジェクトの Simulink モデルは model フォルダーにあります。

メインシステムモデル
テスト用モデル

メインシステムモデル

メインシステムモデルは slexPowerWindowExample です。このモデルは、power_window_control_system ブロックへの入力を生成する driver_switch サブシステムブロックと passenger_switch サブシステムブロックで構成されています。power_window_control_system ブロックは、助手席と運転席の入力の状態を検証します。このブロックは、障害物がウィンドウのパスを遮っているかどうかも判別します。参照先のコントローラーは、ウィンドウシステムのアクティブなバリアントに送信されるウィンドウの動きのコマンド信号を生成します。window_system ブロックの出力は、Control System ブロックへのフィードバックです。

シミュレーションの結果を可視化するために、シミュレーションデータインスペクターが出力データをログに記録し、Simulink 3D Animation™ がウィンドウの動きをアニメーション化します。

モデルバリアント

このプロジェクトのメインシステムモデルは、Variant Subsystem ブロックを使用して、サブシステム内での複数の実装を実現します。シミュレーションの前にアクティブな実装をプログラムで変更できます。メインモデルには、プログラムで変更できるバリアントの選択をそれぞれがもつ 4 つの Variant Subsystem ブロックが含まれています。4 つの Variant Subsystem は以下のとおりです。

slexPowerWindowExample/driver_switch
slexPowerWindowExample/passenger_switch
slexPowerWindowExample/window_system
slexPowerWindowExample/power_window_control_system/detect_obstacle_endstop

各バリアントの選択は、バリアント制御に関連付けられます。バリアントの選択は、そのバリアント制御が true と評価された場合にアクティブになります。

DesignConfig 分類下のファイルを使用して、バリアントの選択の組み合わせを制御してモデルのバリアントコンフィギュレーションを作成できます。モデルのバリアントコンフィギュレーションには以下のものがあります。

パワーウィンドウコントローラーハイブリッドシステムモデル
パワーウィンドウコントローラーおよび詳細なプラントモデル
データ収集効果を使用するパワーウィンドウコントローラー
コントローラーエリアネットワーク (CAN) 通信を使用するパワーウィンドウコントローラー

パワーウィンドウコントローラーハイブリッドシステムモデル

このモデルバリアントでは、Stateflow® および Simulink を使用して、離散イベントのリアクティブ動作と連続時間の動作の両方をモデル化します。モデルは、低次のプラントモデルを使用して上昇動作と下降動作を検証します。このバリアントコンフィギュレーションは、SimHybridPlantLowOrder ショートカットを使用してシミュレートできます。このショートカットを使用すると、このモデルコンフィギュレーションに対応する Variant Subsystem のみがアクティブになります。このモデルではパワー効果は考慮されないため、ログに記録された出力のみが位置になります。シミュレーションデータインスペクターには、ログに記録された位置データが表示されます。

パワーウィンドウコントローラーおよび詳細なプラントモデル

このモデルバリアントでは、電気ドメインと機械ドメインのパワー効果を含む詳細なプラントモデルを使用して、挟まれた物体に対してウィンドウの与える力が 100 N を超えないことを検証していることが示されています。このモデルバリアントでは、Simscape™ Multibody™ および Simscape™ Electrical™ のライセンスが必要です。このバリアントコンフィギュレーションは、SimHybridPlantPowerEffects ショートカットを使用してシミュレートできます。パワーウィンドウコントローラーハイブリッドシステムモデルとは異なり、このバリアントコンフィギュレーションではパワー効果が考慮されます。シミュレーションデータインスペクターには、電機子電流、位置、パワーウィンドウが及ぼす力のログデータが表示されます。

データ収集効果を使用するパワーウィンドウコントローラー

このモデルバリアントは、制御に影響する実装による追加効果を示します。含まれる現象には、電機子電流を測定するための信号調整、測定値の量子化があります。このモデルバリアントでは、Simscape Multibody、Simscape Electrical、DSP System Toolbox™、Fixed-Point Designer™ のライセンスが必要です。このバリアントコンフィギュレーションは、SimHybridPlantPowerEffects+ControlDAQEffects ショートカットを使用してシミュレートできます。パワーウィンドウコントローラーおよび詳細なプラントモデルと同様に、シミュレーションデータインスペクターには、電機子電流、位置、パワーウィンドウが及ぼす力のログデータが表示されます。

CAN 通信を使用するパワーウィンドウコントローラー

このモデルバリアントは、CAN を使用したウィンドウの動きを制御するコマンドのやり取りを示します。このモデルバリアントには、車両の中央コンソールに配置されている可能性があるコマンド生成スイッチが含まれています。このモデルバリアントでは、Simscape Multibody、Simscape Electrical、DSP System Toolbox、Fixed-Point Designer のライセンスが必要です。このバリアントコンフィギュレーションは、Windows OS を実行しているマシンで SimCANCommunication ショートカットを使用してシミュレートできます。

テスト用モデル

パワーウィンドウを制御するステートマシンをテストするには、テスト用のプロジェクトのショートカットを実行できます。コントローラーをテストするためのモデルのショートカットには以下のものがあります。

InteractiveExample
CoverageExample
IncreaseCoverageExample

InteractiveExample

このモデルのショートカットを使用すると、モデル slexPowerWindowCntlInteract が開きます。このモデルには、ステートマシンであるパワーウィンドウコントローラーが含まれています。このモデルには Manual Switch ブロックで選択されるコントローラーへの入力も含まれています。

パワーウィンドウコントローラーには次の 4 つの外部入力があります。

Passenger Input の入力は、次の 3 つの要素をもつベクトルで構成されています。

neutral:助手席の制御スイッチは押されていません。
up:助手席の制御スイッチが up 信号を生成しています。
down:助手席の制御スイッチが down 信号を生成しています。

Driver Input は、次の 3 つの要素をもつベクトルで構成されています。

neutral:運転席の制御スイッチは押されていません。
up:運転席の制御スイッチが up 信号を生成しています。
down:運転席の制御スイッチが down 信号を生成しています。

Window Frame Endstops の入力は、次の 2 つの要素をもつベクトルで構成されています。

0:ウィンドウは上部と下部との間で自由に動いています。
1:物理的制約のためにウィンドウは上部または下部で動きが取れない状態です。

Obstacle Present の入力は、次の 2 つの要素をもつベクトルで構成されています。

0: ウィンドウは上部または下部との間で自由に動いています。
1: ウィンドウの枠には障害物があります。

コントローラーを対話形式でテストするには、モデルのシミュレーションを実行して、Manual Switch ブロックによって目的の入力の組み合わせを選択します。入力の選択が完了したら、内部のコントローラーの状態とコントローラー出力を、特定の入力セットの目的の結果に照らして検証できます。

CoverageExample

このモデルのショートカットを使用すると、モデル slexPowerWindowCntlCoverage が開きます。このモデルには、ステートマシンであるパワーウィンドウコントローラーが含まれています。このモデルには、Repeating Sequence ブロックであるコントローラーへの入力も含まれています。

Simulink Coverage のモデルカバレッジツールを使用すると、ウィンドウの離散イベント制御を検証できます。モデルカバレッジツールは、モデルテストケースがコントローラーの条件付き分岐を実行する範囲を決定します。このツールは、テストケースが与えられた場合に、離散イベント制御のすべての遷移が行われるかどうかを評価します。また、このツールは、特定の遷移を有効にする条件のすべての節が真になるかどうかも評価します。1 つの遷移が複数の節によって有効になる場合があります。たとえば、emergency から neutral に戻る遷移は、100 チックが発生した場合か、端部停止に到達した場合に発生します。

IncreaseCoverageExample

このモデルのショートカットを使用すると、モデル slexPowerWindowCntlCoverageIncrease が開きます。このモデルには、ステートマシンであるパワーウィンドウコントローラーが含まれています。また、複数の入力セットをコントローラーに提供する From Spreadsheet ブロックも含まれています。これらの入力セットは、パワーウィンドウコントローラーにおいてより多くのロジックを実行するために、CoverageExample モデルの入力セットと連携します。

Logged:CoverageExample から記録されます。
LoggedObstacleOffEndStopOn:端部停止に到達できる CoverageExample から記録されます。
LoggedObstacleOnEndStopOff:ウィンドウに障害物がある CoverageExample から記録されます。
LoggedObstacleOnEndStopOn:ウィンドウに障害物があり、端部停止に到達できる CoverageExample から記録されます。
DriverLoggedPassengerNeutral:運転席のみに関して CoverageExample から記録されます。助手席は何のアクションも実行しません。
DriverDownPassengerNeutral:運転席でウィンドウを下げます。助手席は何のアクションも実行しません。
DriverUpPassengerNeutral:運転席でウィンドウを上げます。助手席は何のアクションも実行しません。
DriverAutoDownPassengerNeutral:運転席でウィンドウを 1 秒間下げます (自動下降)。助手席は何のアクションも実行しません。
DriverAutoUpPassengerNeutral:運転席でウィンドウを 1 秒間上げます (自動上昇)。助手席は何のアクションも実行しません。
PassengerAutoDownDriverNeutral:助手席でウィンドウを 1 秒間下げます (自動下降)。運転席は何のアクションも実行しません。
PassengerAutoUpDriverNeutral:助手席でウィンドウを 1 秒間上げます (自動上昇)。運転席は何のアクションも実行しません。

モデルカバレッジのショートカットである GenerateIncreasedCoverage は、Simulink Coverage のモデルカバレッジツールで複数の入力セットを使用することで、ウィンドウの離散イベント制御を検証したり、複数の入力セットのカバレッジレポートを生成したりします。

量的要件

制御のための量的要件は次のとおりです。

ウィンドウは 4 秒以内で完全に開いて閉じなければなりません。
up コマンドが 200 ms ～ 1 秒間発行された場合、ウィンドウは完全に開かなければなりません。down コマンドが 200 ms ～ 1 秒間発行された場合、ウィンドウは完全に閉じなければなりません。
コマンドが発行されてから 200 ミリ秒後にウィンドウが動き始めなければなりません。
物体が存在することを検出する力は、100 N 未満です。
ウィンドウを閉めるときに物体に妨げられた場合は、ウィンドウを閉じるのをやめて、ウィンドウを約 10 cm 下げます。

アクティビティ図とコンテキスト図での要件の記述

アクティビティ図は、仕様をグラフィカルに記述し、システムの動作を理解するのに役立ちます。階層構造により、大規模なシステムでも簡単に解析できます。最上位レベルでは、コンテキスト図によって、システム環境と、検討中のシステムとの相互作用をデータ交換および制御操作の観点から記述します。次に、システムを分解して、プロセスおよび制御仕様 (CSPEC) を含むアクティビティ図を作成できます。

プロセスは階層的な分解を誘導します。各プロセスは、別のアクティビティ図またはプリミティブ仕様 (PSPEC) を使用して指定します。PSPEC は、Simulink ブロック線図など、形式的なセマンティクスをもつ複数の表現で指定できます。また、コンテキスト図では、システム操作のコンテキストをグラフィカルに記述できます。仕様のデータ定義を使用します。

コンテキスト図: パワーウィンドウシステム

次の図は、パワーウィンドウシステムのコンテキスト図を表しています。正方形の枠は環境を表しています。この場合、運転席、助手席およびウィンドウです。運転席と助手席の両方からウィンドウを昇降させるためのコマンドをウィンドウに送信できます。コントローラーは、ウィンドウのアクチュエータに送信される正しいコマンドを推測します (たとえば、運転席コマンドは助手席コマンドよりも優先されます)。さらに、ウィンドウが完全に開閉されたことを確認したり、ウィンドウとウィンドウ枠の間に物体があるかどうかを検出するために、ウィンドウシステムの状態が監視されます。

円 (バブルとも呼ばれます) は、パワーウィンドウコントローラーを表しています。円はプロセスのグラフィカルな表記です。プロセスは、入力データの出力データへの変換を取得します。プリミティブプロセスではさらに生成も行う場合があります。CSPEC は、通常、入力制御信号から出力制御信号を推測するために組み合わせロジックまたは順序ロジックで構成されています。

Simulink 環境での実装は、コンテキスト図の実装: パワーウィンドウシステムを参照してください。

パワーウィンドウシステムのデータ定義

信号	情報の種類	連続/ 離散	データ型	値
DRIVER_COMMAND	データ	離散	集約	`Neutral`, `up`, `down`
PASSENGER_COMMAND	データ	離散	集約	`Neutral`, `up`, `down`
WINDOW_POSITION	データ	連続	実数	0 から 0.4 m
MOVE_UP	コントロール	離散	boolean	`'True'`, `'False'`
MOVE_DOWN	コントロール	離散	boolean	`'True'`, `'False'`

アクティビティ図: パワーウィンドウコントロール

パワーウィンドウコントロールは 3 つのプロセスと CSPEC で構成されています。2 つのプロセスは、運転席および助手席の入力を検証して、システムの状態が与えられた場合に、その入力が意味をもつかどうかを確認します。たとえば、ウィンドウが完全に開いている場合、MOVE DOWN コマンドは無意味です。残りのプロセスは、ウィンドウが完全に開いているか、完全に閉じているかを検出したり、物体が存在するかどうかを検出します。CSPEC は、制御信号を取得し、ウィンドウを上昇させるか下降させるかを推測します (たとえば、物体が存在する場合は、ウィンドウを約 1 秒間または端部停止に到達するまで下降させます)。

パワーウィンドウコントロールのデータ定義

信号	情報の種類	連続/ 離散	データ型	値
DRIVER_COMMAND	データ	離散	集約	`Neutral`, `up`, `down`
PASSENGER_COMMAND	データ	離散	集約	`Neutral`, `up`, `down`
WINDOW_POSITION	データ	連続	実数	0 から 0.4 m
MOVE_UP	コントロール	離散	boolean	`'True'`, `'False'`
MOVE_DOWN	コントロール	離散	boolean	`'True'`, `'False'`

アクティビティ図: VALIDATE DRIVER

VALIDATE DRIVER アクティビティ図の各プロセスはプリミティブであり、次の PSPEC で定義されています。MAKE EXCLUSIVE PSPEC では、安全上の理由から、DOWN コマンドが UP コマンドよりも優先されます。

PSPEC 1.1.1: CHECK DOWN
  CHECKED_DOWN = DOWN and not RESET

PSPEC 1.1.2: CHECK UP
  CHECKED_UP = UP and not RESET

PSPEC 1.1.3: MAKE EXCLUSIVE
  VALIDATED_DOWN    = CHECKED_DOWN
  VALIDATED_UP      = CHECKED_UP and not CHECKED_DOWN
  VALIDATED_NEUTRAL = (NEUTRAL and not (CHECKED_UP and not CHECKED_DOWN))
                        or not (CHECKED_UP or CHECKED_DOWN)

VALIDATE DRIVER のデータ定義

信号	情報の種類	連続/ 離散	データ型	値
DRIVER_COMMAND	データ	離散	集約	`Neutral`, `up`, `down`
PASSENGER_COMMAND	データ	離散	集約	`Neutral`, `up`, `down`
WINDOW_POSITION	データ	連続	実数	0 から 0.4 m
MOVE_UP	コントロール	離散	boolean	`'True'`, `'False'`
MOVE_DOWN	コントロール	離散	boolean	`'True'`, `'False'`

アクティビティ図: VALIDATE PASSENGER

VALIDATE PASSENGER プロセスの内部は、VALIDATE DRIVER プロセスと同じです。違いは、入力と出力の違いだけです。

PSPEC 1.2.1: CHECK DOWN
  CHECKED_DOWN = DOWN and not RESET

PSPEC 1.2.2: CHECK UP
  CHECKED_UP = UP and not RESET

PSPEC 1.2.3: MAKE EXCLUSIVE
  VALIDATED_DOWN    =  CHECKED_DOWN
  VALIDATED_UP      =  CHECKED_UP and not CHECKED_DOWN
  VALIDATED_NEUTRAL = (NEUTRAL and not (CHECKED_UP and not CHECKED_DOWN))
                        or not (CHECKED_UP or CHECKED_DOWN)

Simulink 環境での実装は、アクティビティ図: VALIDATE PASSENGERを参照してください。

VALIDATE PASSENGER のデータ定義

信号	情報の種類	連続/ 離散	データ型	値
NEUTRAL	データ	離散	boolean	`'True'`, `'False'`
UP	データ	離散	boolean	`'True'`, `'False'`
DOWN	データ	離散	boolean	`'True'`, `'False'`
CHECKED_UP	データ	離散	boolean	`'True'`, `'False'`
CHECKED_DOWN	データ	離散	boolean	`'True'`, `'False'`

アクティビティ図: DETECT OBSTACLE ENDSTOP

POWER WINDOW CONTROL アクティビティ図の 3 番目のプロセスは、障害物の存在や、ウィンドウが上部または下部 (ENDSTOP) に到達したことを検出します。この検出メカニズムは、ウィンドウのアクチュエータの電機子電流に基づいています。通常の動作中、この電流は一定の範囲内です。ウィンドウが上部または下部に到達すると、電気モーターは大きな電流 (15 A を超えるか、–15 A 未満) を流して、角速度を維持しようとします。同様に、通常の動作中の電流は (ウィンドウが開いているか、閉じているかに応じて) 約 2 A または –2 A です。障害物がある場合は、この値からわずかに外れます。物体に対するウィンドウの力が 100 N 未満になるようにするため、–2.5 A 未満の電流を検出すると、コントロールは緊急時の動作に切り替わります。この操作は、ウィンドウが上昇する場合にのみ必要であり、このモデルの特定の配線での負の電流に相当します。この機能は、DETECT OBSTACLE ENDSTOP アクティビティ図によって表現されています。

CSPEC 1.3: DETECT OBSTACLE ENDSTOP
  RESET = OBSTACLE or ENDSTOP

PSPEC 1.3.1: DETECT ENDSTOP
  ENDSTOP = WINDOW_POSITION > ENDSTOP_MAX

PSPEC 1.3.2: DETECT OBSTACLE
  OBSTACLE = (WINDOW_POSITION > OBSTACLE_MAX) and MOVE_UP for 500 ms

Simulink 環境での実装は、アクティビティ図: DETECT OBSTACLE ENDSTOPを参照してください。

DETECT OBSTACLE ENDSTOP のデータ定義

信号	情報の種類	連続/ 離散	データ型	値
ENDSTOP_MIN	データ	定数	実数	0.0 m
ENDSTOP_MAX	データ	定数	実数	0.4 m
OBSTACLE_MAX	データ	定数	実数	0.3 m

アクティビティ図の実装: パワーウィンドウコントロール

このトピックでは、パワーウィンドウコントロール向けの離散イベント制御仕様の概要について説明します。

ウィンドウの離散イベント制御は、Stateflow^® チャートによってモデル化できます。Stateflow チャートは、階層と並列性をもつ有限ステートマシンです。このステートマシンには、パワーウィンドウシステムの基本ステート、つまり、up、auto-up、down、auto-down、rest および emergency が含まれています。このステートマシンは、ステート遷移をモデル化し、助手席のコマンドよりも運転席のコマンドを優先することを考慮します。また、ウィンドウの上昇中にウィンドウとウィンドウ枠の間に物体が存在することがソフトウェアで検出されたときにアクティブになる緊急時の動作が含まれています。

パワーウィンドウコントロールの初期 Simulink モデル slexPowerWindowControl は、特定のサンプルレートで動作する離散イベントコントローラーです。

この実装では、パワーウィンドウコントロールサブシステムを開くと、離散イベント制御を含む Stateflow チャートによって、右下隅の傾いた太い棒で表されている CSPEC が表現されていることがわかります。しきい値検出メカニズムは、detect_obstacle_endstop サブシステムでカプセル化されています。

離散イベント制御は、階層と並列性をもつ状態遷移図の概念を拡張する Stateflow モデルです。助手席コマンドは "スーパーステート" 内でカプセル化されているため、ステートの変化は、アクティブな運転席コマンドと一致しません。

助手席のウィンドウの制御を考えます。このウィンドウは、助手席または運転席で上げ下げできます。

このステートマシンには、パワーウィンドウシステムの基本ステート、つまり、up、auto-up、down、auto-down、rest および emergency が含まれています。

対話型テスト

制御入力

slexPowerWindowCntlInteract モデルには、この制御入力がスイッチとして含まれています。これらのスイッチをダブルクリックすることで手動で操作できます。

パワーウィンドウを制御するステートマシンのテストでは、入力テストベクトルを実行し、望ましい内部ステートに到達していることと出力が生成されることを確認します。パワーウィンドウには次の外部入力があります。

助手席の入力
運転席の入力
ウィンドウの上昇または下降
ウィンドウの障害物

各入力は、次の入力をもつベクトルで構成されています。

助手席の入力

要素	説明
`neutral`	助手席の制御スイッチは押されていません。
`up`	助手席の制御スイッチが up 信号を生成しています。
`down`	助手席の制御スイッチが down 信号を生成しています。

運転席の入力

要素	説明
`neutral`	運転席の制御スイッチは押されていません。
`up`	運転席の制御スイッチが up 信号を生成しています。
`down`	運転席の制御スイッチが down 信号を生成しています。

ウィンドウの上昇または下降

要素	説明
`0`	ウィンドウは上部と下部との間で自由に動いています。
`1`	物理的制約のためにウィンドウは上部または下部で動きが取れない状態です。

ウィンドウの障害物

要素	説明
`0`	ウィンドウは上部と下部との間で自由に動いています。
`1`	ウィンドウの枠には障害物があります。

助手席と運転席の入力信号を生成するには、次の表に従って up 信号と down 信号をマッピングします。

入力		出力
up	down	up	down	neutral
`0`	`0`	`0`	`0`	`1`
`0`	`1`	`0`	`1`	`0`
`1`	`0`	`1`	`0`	`0`
`1`	`1`	`0`	`0`	`1`

入力は、パワーウィンドウコントロールスイッチを押すことで生成される up および down イベントから neutral イベントを明示的に生成します。入力は passenger neutral, up, down map および driver neutral, up, down map の真理値表として入力されます。

ケース 1: ウィンドウの上昇

ステートマシンの動作を確認するには、次の手順を実行します。

slexPowerWindowCntlInteract モデルを開きます。
シミュレーションを実行し、次に、助手席ウィンドウ上昇スイッチをダブルクリックします。
物理的なウィンドウのスイッチを 1 秒より長く押すと、上昇スイッチが放されるまで (あるいは、ウィンドウ枠の上部に達し、endstop イベントが生成されるまで) ウィンドウは上昇します。
選択された助手席ウィンドウ上昇スイッチをダブルクリックして放します。
モデルのシミュレーションを実行します。
端部停止スイッチの設定により、endstop イベントが生成されます。

ケース 2: ウィンドウの自動上昇

助手席ウィンドウ上昇スイッチを短時間 (1 秒未満) 押すと、ソフトウェアによって auto-up 動作がアクティブになり、ウィンドウは上昇し続けます。

物理的な助手席ウィンドウ上昇スイッチを短時間 (1 秒未満) 押します。
最終的に、ウィンドウはウィンドウ枠の上部に達し、ソフトウェアによって endstop イベントが生成されます。このイベントによって、ステートマシンが neutral ステートに戻ります。
モデルのシミュレーションを実行します。

ケース 3: 運転席側の優先

助手席ウィンドウ用の運転席スイッチは、運転席コマンドよりも優先されます。この場合のステートマシンの動作を確認するには、次の手順を実行します。

シミュレーションを実行し、次に、助手席ウィンドウ上昇スイッチをダブルクリックしてシステムを passenger up ステートに遷移します。
運転席ウィンドウ下降スイッチをダブルクリックします。
モデルのシミュレーションを実行します。
ステートマシンが運転席制御部に移動し、ウィンドウ上昇出力ではなく、ウィンドウ下降出力を生成するのに注目してください。
運転席の制御をダブルクリックして運転席を up にします。運転席ウィンドウ下降スイッチをダブルクリックします。
ウィンドウ上昇出力、つまり、windowUp = 1 を再度生成する運転席ウィンドウ up ステートに到達します。
ウィンドウとウィンドウ枠の間に物体が存在するときのステート動作を確認するには、障害物スイッチをダブルクリックします。
モデルのシミュレーションを実行します。
次のサンプル時に、ステートマシンは emergencyDown ステートに遷移してウィンドウを数インチ下げます。ソフトウェアによってウィンドウがどの程度下げられるかは、ステートマシンが emergencyDown ステートにある時間によって異なります。この動作は、次の解析フェーズの一部です。
運転席ウィンドウまたは助手席ウィンドウのスイッチがアクティブなままである場合、emergency ステートの終了後、次のサンプル時に、ステートマシンは up または down ステートに遷移します。障害物スイッチもアクティブなままである場合、次のサンプル時にソフトウェアによって emergency ステートが再度アクティブになります。

モデルカバレッジ

制御サブシステムの検証

モデルカバレッジツールを使用してウィンドウの離散イベント制御を検証します。このツールは、モデルのテストケースがコントローラーの条件分岐を実行する範囲を決定するのに役立ちます。このツールは、テストケースが与えられた場合に、離散イベント制御のすべての遷移が行われるかどうかと、特定の遷移を有効にする条件のすべての節が真になるかどうかを評価するのに役立ちます。1 つの遷移が複数の節によって有効になる場合があります。たとえば、emergency から neutral に戻る遷移は、100 チックが発生した場合か、端部停止に到達した場合に発生します。

フルカバレッジを達成するには、使用されるテストケースについて、個々の節を真および偽と評価します。テストケースで実行される遷移のパーセンテージは、"モデルカバレッジ" と呼ばれます。モデルカバレッジは、テストがどの程度の範囲でモデルを実行するかの目安です。

Simulink Coverage™ ソフトウェアを使用して、パワーウィンドウコントローラーに次のテストを適用できます。

位置
位置	1	2	3	4	5	6
助手席 up	0	0	0	0	0	0
助手席 down	0	0	1	0	1	1
運転席 up	0	1	0	1	0	1
運転席 down	1	0	0	1	1	0

このテストでは、すべてのスイッチは時間 0 で非アクティブになっています。通常の 1 秒ステップで、1 つ以上のスイッチのステートが変わります。たとえば、1 秒後に、運転席ウィンドウ下降スイッチがアクティブになります。これらの入力ベクトルを自動的に実行するには、手動スイッチを規定の入力列で置換します。あらかじめ作成されたモデルを確認するには、次の手順を実行します。

slexPowerWindowCntlCoverage モデルを開きます。
モデルのシミュレーションを行い Simulink Coverage カバレッジレポートを生成します。

このレポートにより、slexPowerWindowCntlCoverage モデルでは、このテストによって、driver neutral、up、down map ブロックからの判定結果の 100% が処理されていることがわかります。ただし、このテストでは passenger neutral、up、down map ブロックは 50% のカバレッジしか得られていません。このカバレッジは、slexPowerWindowCntlCoverage 全体のカバレッジが 45% で、slexPowerWindowControl モデル全体のカバレッジが 42% であることを意味します。カバレッジのレベルに影響を与えるいくつかの要因を次に示します。

passenger up ブロックが変化しない。
endstop および obstacle ブロックが変化しない。

モデルカバレッジを大きくする

合計カバレッジを 100% まで上げるには、運転席、助手席、障害物および端部停止の設定のすべての考えられる組み合わせを考慮する必要があります。制御動作に満足であれば、パワーウィンドウシステムを作成できます。詳細については、モデルベースデザインを使用したモデルの作成を参照してください。

この例は、ウィンドウの離散イベント制御の検証用にモデルカバレッジを大きくします。最初に、この例はモデルカバレッジのベースラインとして slexPowerWindowCntlCoverage からの入力を使用します。次に、ウィンドウの離散イベント制御をさらに演習するために、追加の入力セットを作成します。スプレッドシートファイル inputCntlCoverageIncrease.xlsx には、シートごとに 1 つの入力セットを使用するこれらの入力セットが含まれています。

この例では、コントローラーモデル slexPowerWindowControl からスプレッドシートテンプレートを作成するユーティリティ関数 slexPowerWindowSpreadsheetGeneration により、inputCntlCoverageIncrease.xlsx が作成されます。inputCntlCoverageIncrease.xlsx で、関数はコントローラーモデル内の信号名としてブロック名を使用します。slexPowerWindowSpreadsheetGeneration はシート名を定義します。ユーティリティ関数 slexWindowSpreadsheetAddInput は inputCntlCoverageIncrease.xlsx に信号データを取り込みます。

これらの入力セットのシート名と説明は次のとおりです。

シート名	説明
`Logged`	`slexPowerWindowCntlCoverage` で記録された入力
`LoggedObstacleOffEndStopOn`	`slexPowerWindowCntlCoverage` で記録された入力 (端部停止に到達可能)
`LoggedObstacleOnEndStopOff`	`slexPowerWindowCntlCoverage` で記録された入力 (ウィンドウの障害物あり)
`LoggedObstacleOnEndStopOn`	`slexPowerWindowCntlCoverage` で記録された入力 (ウィンドウの障害物あり、端部停止に到達可能)
`DriverLoggedPassengerNeutral`	`slexPowerWindowCntlCoverage` で記録された入力 (運転席のみ。助手席の操作なし)
`DriverDownPassengerNeutral`	運転席側でウィンドウを下降し、助手席側での操作はなし
`DriverUpPassengerNeutral`	運転席側でウィンドウを上昇し、助手席側での操作はなし
`DriverAutoDownPassengerNeutral`	運転席側で 1 秒間ウィンドウを下降し (auto-down)、助手席側での操作はなし
`DriverAutoUpPassengerNeutral`	運転席側で 1 秒間ウィンドウを上昇し (auto-up)、助手席側での操作はなし
`PassengerAutoDownDriverNeutral`	助手席側で 1 秒間ウィンドウを下降し (auto-down)、運転席側での操作はなし
`PassengerAutoUpDriverNeutral`	助手席側で 1 秒間ウィンドウを上昇し (auto-up)、運転席側での操作はなし

これらの入力ベクトルを自動的に実行するには、inputCntlCoverageIncrease.xlsx ファイルを使用して離散イベント制御への入力を From Spreadsheet ブロックで置き換えます。このファイルには複数の入力セットが含まれています。あらかじめ作成されたモデルを確認するには、次の手順を実行します。

slexPowerWindowCntlCoverageIncrease モデルを開きます。
複数の入力セットに対して Simulink Coverage カバレッジレポートを生成するには、モデル内で Run Coverage サブシステムをダブルクリックします。
slexPowerWindowCntlCoverageIncrease モデルの場合、複数の入力セットを使用したことによって slexPowerWindowControl モデルの全体のカバレッジが 42% から 78% に向上したことがレポートから確認できます。次の入力セットが不足しているため、カバレッジレベルは 100% 未満です。
- 助手席の up ステート
- 運転席の up ステートおよび down ステート
- 助手席の auto-down ステートおよび auto-up ステート

モデルベースデザインを使用したモデルの作成

コンテキスト図の実装: パワーウィンドウシステム

コンテキスト図として表される要件については、コンテキスト図: パワーウィンドウシステムを参照してください。

Simulink モデルを作成してコンテキスト図に類似させます。

プラント動作を 1 つのサブシステムに配置します。
運転席および助手席のスイッチを含む 2 つのサブシステムを作成します。
物体の有無を簡単に切り替えられるように、制御メカニズムを追加します。
1 つのサブシステムにコントロールを配置します。
新しいサブシステムを接続します。
このモデルの実装を表示するには、slexPowerWindowExample モデルを開きます。

パワーウィンドウコントロールのアクティビティ図 (アクティビティ図: パワーウィンドウコントロール) を使用して、コンテキスト図のパワーウィンドウコントローラーを部分に分けることができます。この図は、コンテキスト図に存在する入出力信号を、その発信元を簡単にたどれるようにするために示しています。

パワーウィンドウコントロールシステムの実装

完全な要件を満たすには、パワーウィンドウコントロールは運転席と助手席の入力の検証を処理して端部停止を検出しなければなりません。

アクティビティ図として表される要件については、アクティビティ図: パワーウィンドウコントロールを参照してください。

slexPowerWindowExample/power_window_control_system ブロックをダブルクリックして、次のサブシステムを開きます。

アクティビティ図の実装: 検証

アクティビティ図として表される要件については、アクティビティ図: VALIDATE DRIVERおよびアクティビティ図: VALIDATE PASSENGERを参照してください。

アクティビティ図により、確実に正しい操作をするために運転席および助手席コマンドのデータ検証機能が追加されます。たとえば、ウィンドウが上部に到達したときに、ソフトウェアは up コマンドをブロックします。実装により、各検証プロセスは新しいサブシステムに分解されます。運転席コマンドの検証を考えます (助手席コマンドの検証も同様です)。モデルが up または down コマンドを実行できるかどうかを、以下に従って確認します。

モデルが down コマンドを許可するのは、ウィンドウが完全に開かれていない場合だけです。
モデルが up コマンドを許可するのは、ウィンドウが完全に閉じられておらず、物体が検出されない場合だけです。

3 番目のアクティビティ図のプロセスでは、ソフトウェアによって 3 つのコマンド (neutral、up、down) のうちの 1 つのみがコントローラーに送信されることを確認します。実際の実装では、up および down の両方が同時に真である可能性があります (たとえば、スイッチバウンスの影響のため)。

power_window_control_system サブシステムのうち、これが validate_driver_state サブシステムです。

power_window_control_system サブシステムのうち、これが validate_passenger_state サブシステムです。

アクティビティ図の実装: DETECT OBSTACLE ENDSTOP

アクティビティ図として表される要件については、アクティビティ図: DETECT OBSTACLE ENDSTOPを参照してください。

slexPowerWindowExample モデルの power_window_control_system/detect_obstacle_endstop ブロックは、Variant Subsystem ブロックの連続バリアントにこのアクティビティ図を実装します。設計反復中に、バリアントをさらに追加できます。

slexPowerWindowExample モデルの power_window_control_system/detect_obstacle_endstop/Continuous/verify_position ブロックをダブルクリックします。

ハイブリッド動的システム: 離散イベント制御と連続プラントの結合

離散イベント制御を設計および検証してから、これを連続時間プラント動作に統合します。このステップは、最も簡単なバージョンのプラントを使用する設計の最初の反復です。

プロジェクトで、[ファイル] に移動して [プロジェクト] をクリックします。configureModel フォルダーで、slexPowerWindowContinuous ユーティリティを実行してモデルを開いて初期化します。

window_system ブロックは Variant Subsystem ブロックを使用して、プラントモデリングにおける忠実度のさまざまなレベルを許可します。window_system/Continuous/2nd_order_window_system ブロックをダブルクリックして連続バリアントを表示します。

このプラントは、入力が階段状に変化する 2 階微分方程式としてモデル化されます。

Stateflow チャートが windowUp を生成する場合、入力は 1 です。
Stateflow チャートが windowDown を生成する場合、入力は –1 です。
そうでない場合、入力は 0 です。

このフェーズにより、離散イベントステート動作と、そのサンプルレート、ウィンドウの動きの連続動作間の相互作用の解析が可能になります。ウィンドウ枠の上部と下部を生成するために、次のしきい値があります。

endStop
障害物が存在する場合のイベント、つまり obstacle
その他のイベント

slexPowerWindowExample モデルの power_window_control_system/detect_obstacle_endstop/Continuous/verify_position ブロックをダブルクリックして連続バリアントを表示します。

slexPowerWindowContinuous configureModel ユーティリティの実行中は、モデルは連続時間ソルバー ode23 (Bogacki-Shampine) を使用します。

システムの構造解析の結果は、次のとおりです。

システムの機能的分解
システム信号の仕様を使用したデータ定義
タイミング制約

構造解析には実装アーキテクチャも含まれます (ここでは説明しません)。

この実装により、物体の有無を簡単に切り替えられるように、制御メカニズムも追加されます。

予想されるコントローラーの応答. ウィンドウの動きを表示するには、[プロジェクトのショートカット] で SimHybridPlantLowOrder をダブルクリックします。あるいは、タスク slexPowerWindowContinuousSim を実行できます。

position スコープは、コントローラーからの予想される結果を示します。30 cm 上昇した後、モデルにより obstacle イベントが生成され、Stateflow チャートが emergencyDown ステートに遷移します。このステートでは、ウィンドウが約 10 cm 下がるまで windowDown が出力されます。助手席ウィンドウ上昇スイッチがオンのままであるため、ウィンドウは再度上昇を開始し、このプロセスが繰り返されます。シミュレーションを停止し、position スコープを開いて振動プロセスを観察します。緊急時には、離散イベント制御により、ウィンドウが約 10 cm 下げられます。

パワー効果の詳細なモデル化

離散イベント制御と連続ダイナミクスの初期解析後に、詳細なプラントモデルを使用して、より現実的な状況において性能を評価できます。モデルは、このような詳細レベルのパワードメイン内で、つまり、エネルギーの流れとして設計されることが最適です。いくつかのドメイン固有の MathWorks ブロックセットによってこれが容易になります。

エネルギーの流れを考慮するには、パワーエレクトロニクスとマルチボディシステムで構成されるより詳細なバリアントを window_system Variant Subsystem に追加します。

モデルを開いてさらに詳細なプラントバリアントを調査するには、プロジェクトで configureModel slexPowerWindowPowerEffects を実行します。

slexPowerWindowExample モデルの window_system/Power Effects - Visualization/detailed_window_system ブロックをダブルクリックします。

パワーエレクトロニクスサブシステム. モデルは、離散イベントコントローラーによって生成された制御信号を、ウィンドウを動かす DC モーターを駆動するのに十分強力になるように増幅しなければなりません。

増幅モジュールがこの動作をモデル化します。これは、スイッチが DC モーターをバッテリー電圧または接地のいずれかに接続することを示しています。バッテリーを逆に接続することによって、システムは負の電圧を生成して、ウィンドウを昇降したり、静止したままにすることができます。ウィンドウは常に最大電力で駆動されます。つまり、指定速度を適用する DC モーターコントローラーはありません。

実装を確認するには、slexPowerWindowExample モデルの window_system/Power Effects - Visualization/detailed_window_system/amplification_up ブロックをダブルクリックします。

マルチボディシステム. この実装では、ウィンドウは Simscape™ Multibody™ ブロックを使用してモデル化されます。

アクチュエータ実装を確認するには、slexPowerWindowExample モデルの window_system/Power Effects - Visualization/detailed_window_system/actuator ブロックをダブルクリックします。

ウィンドウの実装を確認するには、slexPowerWindowExample モデルの window_system/Power Effects - Visualization/detailed_window_system/plant ブロックをダブルクリックします。

この実装では、ボディ、ジョイントおよびアクチュエータの Simscape Multibody ブロックが使用されます。ウィンドウモデルは、次の要素で構成されます。

ウォームギア
ウィンドウホルダーを垂直方向に移動するレバー

次の図は、機械的部品がどのように動くかを示しています。

設計に対する反復処理. より詳細な実装の重要な影響は、ウィンドウ位置測定が利用できないことです。その代わり、モデルは DC モーターの電流を測定して、端部停止の検出と、障害物が存在するかどうかの検出に使用します。システム設計の次の段階では、制御を解析して、障害物が存在するときに過度の力を発生させていないことを確認します。

元のシステムでは、設計により、ウィンドウ位置に基づく障害物と端部停止の検出は削除され、電流ベースの実装により置き換えられます。また、プロセスはコントローラーと位置および力測定に接続されます。使用されるさまざまな信号を反映するようにするには、データ定義を変更しなければなりません。さらに、パワー効果のため、単位はアンペアになっています。

PSPEC 1.3.1: DETECT ENDSTOP
  ENDSTOP = ARMATURE_CURRENT > ENDSTOP_MAX

PSPEC 1.3.2: DETECT OBSTACLE
  OBSTACLE = (ARMATURE_CURRENT > OBSTACLE_MAX) and MOVE_UP for 500 ms

PSPEC 1.3.3: ABSOLUTE VALUE
  ABSOLUTE_ARMATURE_CURRENT = abs(ARMATURE_CURRENT)

次の表は、コンテキスト図: パワーウィンドウシステムのデータ定義の追加の信号の一覧です。

コンテキスト図: パワーウィンドウシステムのデータ定義の変更

信号	情報の種類	連続/ 離散	データ型	値
ARMATURE_CURRENT	データ	連続	実数	–20 から 20 A

次の表は、アクティビティ図: DETECT OBSTACLE ENDSTOP のデータ定義で変更された信号の一覧です。

アクティビティ図: DETECT OBSTACLE ENDSTOP のデータ定義の変更

信号	情報の種類	連続/ 定数	データ型	値
ABSOLUTE_ARMATURE_CURRENT	データ	連続	実数	0 から 20 A
ENDSTOP_MAX	データ	定数	実数	15 A
OBSTACLE_MAX	データ	定数	実数	2.5 A

ウィンドウのサブシステムを確認するには、slexPowerWindowExample モデルの window_system/Power Effects - Visualization/detailed_window_system/plant/window ブロックをダブルクリックします。

実装ではルックアップテーブルを使用して、制御のロバスト性を評価できるようにするためにノイズを追加します。摩擦のサブシステムの実装を確認するには、slexPowerWindowExample モデルの window_system/Power Effects - Visualization/detailed_window_system/plant/window/friction ブロックをダブルクリックします。

制御則の評価

理想的な連続プラントでは endStop および obstacle イベントの生成のためのウィンドウ位置へのアクセスを許可します。より現実的な実装においては、モデルがこれらのイベントを、アクセス可能な物理的変数から生成しなければなりません。パワーウィンドウシステムの場合、この物理的変数とは通常、ウォームギアを駆動する DC モーターの電機子電流 Ia です。

ウィンドウが動いている間、この電流の値は約 2 A になります。ウィンドウのスイッチをオンにすると、約 10 A の値に到達する過渡電流が流れます。モデルにより端部停止の検出がアクティブになるのは、電流が 15 A を超えたときです。モデルでは、この電流は入力電圧が正か負かに関係なく、モーターの角速度がほぼ 0 に保たれているときに流れます。

この設定では、物体の存在を検出することは難しくなります。安全のため、ウィンドウの力は 100 N を超えるべきではないと規制されているため、物体は、10 A よりはるかに低い電機子電流によって検出される必要があります。しかし、この動作は、通常操作中に達する過渡値と矛盾しています。

過渡値に達したときに物体の検出を無効にする制御則を実装します。システムによって 2 A を超える電機子電流が検出されると、物体が存在すると見なされ、離散イベント制御の emergencyDown ステートに入ります。force スコープウィンドウ (測定は N 単位) を開いて、物体が存在し、ウィンドウがその速度を逆転させるときに及ぼされる力が 100 N 未満のままであることを確認してください。

実際には、はるかに高度な制御則が実装可能であり、実装されています。たとえば、個々の車両の摩擦特性とその経時変化をエミュレートするために、ニューラルネットワークベースの学習フィードフォワード制御手法を実装できます。

動作中のシステムの可視化

Simulink 3D Animation™ ソフトウェアがインストールされている場合、仮想現実の世界を通して動作中のシステムの幾何学的形状を表示できます。VR Sink ブロックがまだ開かれていない場合、slexPowerWindowExample/window_world/Simulink_3D_Animation View モデルで VR Sink ブロックをダブルクリックします。

スティッフなソルバーでモデルのシミュレーションを実行するには、次の手順を実行します。

プロジェクトで、タスク slexPowerWindowPowerEffectsSim を実行します。このバッチジョブは、ソルバーを ode23tb (stiff/TR-BDF2) に設定します。
slexPowerWindowExample モデルの passenger_switch/Normal ブロックで、助手席ウィンドウ上昇スイッチをオンに設定します。
slexPowerWindowExample モデルの driver_switch/Normal ブロックで、運転席ウィンドウ上昇スイッチをオフに設定します。
モデルのシミュレーションを実行します。
シミュレーション時間が 10 ミリ秒から 1 秒までの間に、slexPowerWindowExample/passenger_switch/Normal ブロックの助手席ウィンドウ上昇スイッチをオフにして、自動上昇動作を開始します。
ウィンドウホルダーが垂直方向に移動してウィンドウを閉じ始めることを確認します。モデルが物体に遭遇すると、ウィンドウは下げられます。
slexPowerWindowExample モデルの passenger_switch/Normal ブロックの運転席ウィンドウ下降スイッチをダブルクリックしてウィンドウを完全に下げ、モデルのシミュレーションを実行します。このブロックでは、1 秒未満のシミュレーション時間に、運転席ウィンドウ下降スイッチをオフにして、自動下降動作を開始します。
ウィンドウがウィンドウ枠の下部に到達すると、シミュレーションを停止します。
位置測定 (m 単位) と電機子電流 (Ia) 測定 (A 単位) を見てみましょう。
メモ
通常の動作中の電機子電流トランジェントの絶対値は 10 A を超えません。ウィンドウを上昇させるために必要な電機子電流の絶対値が 2.5 A (実際は、–2.5 A 未満) を超えると、モデルが障害物を検出します。通常の動作中、この値は約 2 A です。この測定値をよく見るには、スコープを拡大しなければなりません。電機子電流の絶対値が 15 A を超えると、モデルがウィンドウの端部停止を検出します。
通常動作中の電機子電流の変化の原因は、ジョイントの速度と位置を検出することと、ウィンドウ固有の係数を適用することによって含められる摩擦です。

現実的な電機子測定

パワーウィンドウコントロールで使用される電機子電流は、アクチュエータモデルの使用によってアクセス可能な理想値です。より現実的な状況においては、この電流値は、データ収集コンポーネントによって測定されなければなりません。

データ収集コンポーネントを含めるには、より現実的な測定バリアントを window_system Variant Subsystem に追加します。この現実的な測定バリアントには、電圧測定に基づいて電流が導出される信号調整ブロックが含まれます。

モデルを開いて現実的な測定を構成するには、プロジェクトで configureModel タスク slexPowerWindowRealisticArmature を実行します。

Realistic Armature - Communications Protocol ブロックの内容を表示するには、SlexPowerWindowExample モデルの window_system/Realistic Armature - Communications Protocol/detailed_window_system_with_DAQ をダブルクリックします。

この測定電圧は、特定のビット数に基づいて離散化するアナログデジタルコンバーター (ADC) の範囲内です。結果の値は、抵抗器の値と ADC の範囲に基づいてスケーリングしなければなりません。

これらの演算を固定小数点計算として含めます。特定の範囲で必要な分解能を実装するには、8 ビットではなく 16 ビットが必要になります。

次のような同じシナリオを検討します。

slexPowerWindowExample/passenger_switch/Normal ブロックで、助手席ウィンドウ上昇スイッチを設定します。
シミュレーションを実行します。
しばらくしてから、slexPowerWindowExample/passenger_switch/Normal ブロックで、助手席ウィンドウ上昇スイッチをオフにします。
ウィンドウが下げられたら、slexPowerWindowExample/passenger_switch/Normal ブロックの運転席ウィンドウ下降スイッチをクリックします。
しばらくしてから、slexPowerWindowExample/passenger_switch/Normal ブロックの運転席ウィンドウ下降スイッチをオフにします。
ウィンドウがウィンドウ枠の下部に到達すると、シミュレーションを停止します。
armature_current スコープウィンドウを拡大して離散化された外観を確認します。

通信プロトコル

パワーウィンドウの出力制御と同様に、ハードウェアは入力イベントを生成しなければなりません。この場合のハードウェアとは、ドアおよびセンターコントロールパネルにあるウィンドウコントロールスイッチです。ローカルプロセッサはこのようなイベントを生成し、CAN バスによってウィンドウコントローラーに伝達します。

これらのイベントを含めるには、CAN バスからの入力を含むバリアントを追加して、CAN バスで供給されるイベントを生成するコンポーネントを運転席スイッチおよび助手席スイッチの Variant Subsystem に切り替えます。モデルを開いて CAN 通信プロトコルを構成するには、configureModel タスク slexPowerWindowCommunicationProtocolSim を実行します。

スイッチサブシステムの実装を確認するには、slexPowerWindowExample/driver_switch/Communication Protocol/driver ウィンドウコントロールスイッチブロックをダブルクリックします。

ウィンドウ制御システムに非常によく似た構造を確認します。この構造には、以下が含まれます。

制御スイッチを表すプラントモデル
信号調整コンポーネントを含むデータ収集サブシステム
物理スイッチからのコマンドを論理コマンドにマップするための制御モジュール
車両のデータバスにイベントを送る CAN モジュール

CAN バスを使用する他のシステムなどの通信影響や、記述されているフェーズに類似した現実感を付加できます。各フェーズでは、さらに現実的な状況において離散イベントコントローラーを解析できます。十分な詳細が得られたら、特定のターゲットプラットフォームについてコントローラーのコードを自動的に生成できます。

制御サブシステム用の自動コード生成

設計された制御モデル slexPowerWindowExample のコードを生成できます。

コントローラーのサンプルレートを表示します。Simulink エディターの [デバッグ] タブで、[情報のオーバーレイ] 、 [サンプル時間] 、 [色] を選択します。コントローラーが一定のサンプルレートで動作することを確認します。
power_window_control_system ブロックを右クリックして [C/C++ コード] 、 [このサブシステムをビルド] を選択します。

参考文献

Mosterman, Pieter J., Janos Sztipanovits, and Sebastian Engell, "Computer-Automated Multiparadigm Modeling in Control Systems Technology," IEEE Transactions on Control Systems Technology, Vol. 12, Number 2, 2004, pp. 223–234.

詳細

プロジェクト管理

パワー ウィンドウ

パワー ウィンドウ コントロール プロジェクト