Main Content

パワー ウィンドウ

パワー ウィンドウについて

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

  • ウィンドウおよびサンルーフの開閉

  • ミラーおよびヘッドライトの調節

  • ドアのロックおよびロック解除

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

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

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

  • タイミングの要件や力の要件などの、ウィンドウ制御システムの量的要件

  • アクティビティ図で記述するシステム要件

  • アクティビティ図で使用する信号のデータ定義

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

  • システムのコンポーネントの管理

  • モデルの作成

  • システム シミュレーションの結果の検証

  • コードの生成

この例で使用する MathWorks ソフトウェア

この例では、Simulink に加えて次の MathWorks® 製品も使用します。

  • DSP System Toolbox™

  • Fixed-Point Designer™

  • Simscape™ Multibody™

  • Simscape Electrical™

  • Simscape

  • Simulink® 3D Animation™

  • Simulink Real-Time™

  • Simulink Coverage™

  • Stateflow®

量的要件

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

  • ウィンドウは 4 秒以内で完全に開いて閉じなければなりません。

  • up コマンドが 200 ms ～ 1 秒間発行された場合、ウィンドウは完全に開かなければなりません。down コマンドが 200 ms ～ 1 秒間発行された場合、ウィンドウは完全に閉じなければなりません。

  • コマンドが発行されてから 200 ミリ秒後にウィンドウが動き始めなければなりません。

  • 物体が存在することを検出する力は、100 N 未満です。

  • ウィンドウを閉めるときに物体に妨げられた場合は、ウィンドウを閉じるのをやめて、ウィンドウを約 10 cm 下げます。

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

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

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

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

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

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

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

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

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

Simulink 環境での実装は、アクティビティ図の実装: パワー ウィンドウ コントロールを参照してください。

アクティビティ図: 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)

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

アクティビティ図: 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を参照してください。

アクティビティ図: 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を参照してください。

データ定義

機能的分解は、各プロセスをその分解またはプリミティブ仕様 (PSPEC) によって厳密に指定します。さらに、アクティビティ図内の信号も形式的に指定しなければなりません。これらの指定のためにデータ定義を使用します。

次の表は、アクティビティ図で使用される信号のデータ定義です。

関連するアクティビティ図は、コンテキスト図: パワー ウィンドウ システムを参照してください。

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

信号情報の種類連続/
離散		データ型値

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'

関連するアクティビティ図は、アクティビティ図: パワー ウィンドウ コントロールを参照してください。

アクティビティ図: パワー ウィンドウ コントロールのデータ定義

信号情報の種類連続/
離散		データ型値

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 のデータ定義

信号情報の種類連続/
離散		データ型値

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 のデータ定義

信号情報の種類連続/
離散		データ型値

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を参照してください。

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

信号情報の種類連続/
離散		データ型値

ENDSTOP_MIN

データ

定数

実数

0.0 m

ENDSTOP_MAX

データ

定数

実数

0.4 m

OBSTACLE_MAX

データ

定数

実数

0.3 m

モデル設計は、さらに詳細な実装の調査に従って繰り返します。モデル設計が詳細の導入に従ってどのように繰り返されるかについては、設計に対する反復処理を参照してください。

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

MATLAB® および Simulink は、初期仕様からコード生成までの組み込み制御設計のためのモデルベース デザインをサポートします。大規模なプロジェクトを整理して他の人と作業を共有するには、プロジェクト管理を使用します。

パワー ウィンドウ コントロール プロジェクトでは、MathWorks ツールとモデルベース デザイン プロセスを使用して、自動車のパワー ウィンドウ システムの構想から実装に至る方法を示します。これはファイルやその他のモデル コンポーネントの整理にプロジェクトを使用します。

さらに、この例では、モデルをシステムのドキュメンテーションにリンクする方法を示します。

パワー ウィンドウ コントローラー プロジェクトの調査

  1. パワー ウィンドウ コントローラー プロジェクトを開くには、MATLAB コマンド ウィンドウに、次のように入力します。

    slexPowerWindowStart

  2. プロジェクト フォルダーを調査します。特に、task フォルダーに注意してください。このフォルダーには、モデルに対して頻繁に使用するタスクを実行するスクリプトが含まれています。パワー ウィンドウ コントローラー プロジェクトに対して、これらのスクリプトは以下を実行します。

    • コントローラー エリア ネットワーク (CAN) でのウィンドウの動きを制御するモデルを設定します。

    • Stateflow および Simulink ソフトウェアを使用して、離散イベントのリアクティブ動作および連続時間の動作を低次のプラント モデルを使用してモデル化します。

    • 電気ドメインと機械ドメインのパワー効果を含むさらに詳細なプラント モデルを使用してモデルを設定します。プラント モデルは、挟まれた物体上でウィンドウが及ぼす力を評価します。

    • 測定値の量子化など、モデルを変更する可能性のあるその他の効果を含むモデルを使用してモデルを設定します。

      メモ

      これらのスクリプトは、モデルのシミュレーションも実行します。モデルの構成のみを行うには、configureModel フォルダーにあるスクリプトを参照してください。

    • 大きくしたカバレッジ モデルを使用して、モデル カバレッジ レポートを作成します。

  3. [プロジェクトのショートカット] セクションには、ダブルクリックして次のような一般的なタスクを実行できるクイック アクセス コマンドがあります。

    • プロジェクトの MATLAB パスへの追加。

    • 対話型テストの実行。

    • モデル カバレッジを使用したモデルのテストの検証。

    • メイン モデルを開く。

    • さまざまな構成でのモデルのシミュレーション。

    • 大きくしたモデル カバレッジ用にモデル カバレッジ レポートを作成します。

    • モデル カバレッジを大きくするために使用するモデルを開きます。

Simulink パワー ウィンドウ コントローラー

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

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

ウィンドウの離散イベント制御は、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 信号をマッピングします。

入力出力
updownupdownneutral

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: ウィンドウの上昇.  ステート マシンの動作を確認するには、次の手順を実行します。

  1. slexPowerWindowCntlInteract モデルを開きます。

  2. シミュレーションを実行し、次に、助手席ウィンドウ上昇スイッチをダブルクリックします。

    物理的なウィンドウのスイッチを 1 秒より長く押すと、上昇スイッチが放されるまで (あるいは、ウィンドウ枠の上部に達し、endstop イベントが生成されるまで) ウィンドウは上昇します。

  3. 選択された助手席ウィンドウ上昇スイッチをダブルクリックして放します。

  4. モデルのシミュレーションを実行します。

    端部停止スイッチの設定により、endstop イベントが生成されます。

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

  1. 物理的な助手席ウィンドウ上昇スイッチを短時間 (1 秒未満) 押します。

    最終的に、ウィンドウはウィンドウ枠の上部に達し、ソフトウェアによって endstop イベントが生成されます。このイベントによって、ステート マシンが neutral ステートに戻ります。

  2. モデルのシミュレーションを実行します。

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

  1. シミュレーションを実行し、次に、助手席ウィンドウ上昇スイッチをダブルクリックしてシステムを passenger up ステートに遷移します。

  2. 運転席ウィンドウ下降スイッチをダブルクリックします。

  3. モデルのシミュレーションを実行します。

  4. ステート マシンが運転席制御部に移動し、ウィンドウ上昇出力ではなく、ウィンドウ下降出力を生成するのに注目してください。

  5. 運転席の制御をダブルクリックして運転席を up にします。運転席ウィンドウ下降スイッチをダブルクリックします。

    ウィンドウ上昇出力、つまり、windowUp = 1 を再度生成する運転席ウィンドウ up ステートに到達します。

  6. ウィンドウとウィンドウ枠の間に物体が存在するときのステート動作を確認するには、障害物スイッチをダブルクリックします。

  7. モデルのシミュレーションを実行します。

    次のサンプル時に、ステート マシンは emergencyDown ステートに遷移してウィンドウを数インチ下げます。ソフトウェアによってウィンドウがどの程度下げられるかは、ステート マシンが emergencyDown ステートにある時間によって異なります。この動作は、次の解析フェーズの一部です。

    運転席ウィンドウまたは助手席ウィンドウのスイッチがアクティブなままである場合、emergency ステートの終了後、次のサンプル時に、ステート マシンは up または down ステートに遷移します。障害物スイッチもアクティブなままである場合、次のサンプル時にソフトウェアによって emergency ステートが再度アクティブになります。

モデル カバレッジ

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

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

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

位置ステップ
0123456
助手席 up 0000000
助手席 down0001011
運転席 up 0010101
運転席 down0100110

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

  1. MATLAB コマンド ウィンドウに、次のように入力します。

    slexPowerWindowCntlCoverage

  2. モデルのシミュレーションを行い 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 ブロックで置き換えます。このファイルには複数の入力セットが含まれています。あらかじめ作成されたモデルを確認するには、次の手順を実行します。

  1. MATLAB コマンド ウィンドウに、次のように入力します。

    slexPowerWindowCntlCoverageIncrease

  2. 複数の入力セットに対して Simulink Coverage カバレッジ レポートを生成するには、モデル内で Run Coverage サブシステムをダブルクリックします。

    slexPowerWindowCntlCoverageIncrease モデルの場合、複数の入力セットを使用したことによって slexPowerWindowControl モデルの全体のカバレッジが 42% から 78% に向上したことがレポートから確認できます。次の入力セットが不足しているため、カバレッジ レベルは 100% 未満です。

    • 助手席の up ステート

    • 運転席の up ステートおよび down ステート

    • 助手席の auto-down ステートおよび auto-up ステート

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

モデルベース デザインを使用する理由

モデルベース デザインでは、装置の開発から設計、実装、テストまで、システム モデルが開発過程の中心となります。モデルベース デザインを使用して、次の処理を行います。

  • プロジェクト チーム全員が共通の設計環境を使用する。

  • 設計を要件に直接リンクする。

  • テストと設計を統合し、継続的にエラーの検出と訂正を行う。

  • マルチドメイン シミュレーションを通してアルゴリズムを改良する。

  • 組み込みソフトウェア コードを自動生成する。

  • テスト スイートを開発し再利用する。

  • モデルのドキュメンテーションを自動生成する。

  • 設計を再利用して、複数のプロセッサやハードウェア ターゲットすべてにシステムを配布する。

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

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

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

  1. プラント動作を 1 つのサブシステムに配置します。

  2. 運転席および助手席のスイッチを含む 2 つのサブシステムを作成します。

  3. 物体の有無を簡単に切り替えられるように、制御メカニズムを追加します。

  4. 1 つのサブシステムにコントロールを配置します。

  5. 新しいサブシステムを接続します。

  6. このモデルの実装を表示するには、MATLAB コマンド ウィンドウに、次のように入力します。

    slexPowerWindowStart

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

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

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

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

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 ブロックをダブルクリックします。

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

  1. プロジェクトで、タスク slexPowerWindowPowerEffectsSim を実行します。このバッチ ジョブは、ソルバーを ode23tb (stiff/TR-BDF2) に設定します。

  2. slexPowerWindowExample モデルの passenger_switch/Normal ブロックで、助手席ウィンドウ上昇スイッチをオンに設定します。

  3. slexPowerWindowExample モデルの driver_switch/Normal ブロックで、運転席ウィンドウ上昇スイッチをオフに設定します。

  4. モデルのシミュレーションを実行します。

  5. シミュレーション時間が 10 ミリ秒から 1 秒までの間に、slexPowerWindowExample/passenger_switch/Normal ブロックの助手席ウィンドウ上昇スイッチをオフにして、自動上昇動作を開始します。

  6. ウィンドウ ホルダーが垂直方向に移動してウィンドウを閉じ始めることを確認します。モデルが物体に遭遇すると、ウィンドウは下げられます。

  7. slexPowerWindowExample モデルの passenger_switch/Normal ブロックの運転席ウィンドウ下降スイッチをダブルクリックしてウィンドウを完全に下げ、モデルのシミュレーションを実行します。このブロックでは、1 秒未満のシミュレーション時間に、運転席ウィンドウ下降スイッチをオフにして、自動下降動作を開始します。

  8. ウィンドウがウィンドウ枠の下部に到達すると、シミュレーションを停止します。

  9. 位置測定 (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 ビットが必要になります。

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

  1. slexPowerWindowExample/passenger_switch/Normal ブロックで、助手席ウィンドウ上昇スイッチを設定します。

  2. シミュレーションを実行します。

  3. しばらくしてから、slexPowerWindowExample/passenger_switch/Normal ブロックで、助手席ウィンドウ上昇スイッチをオフにします。

  4. ウィンドウが下げられたら、slexPowerWindowExample/passenger_switch/Normal ブロックの運転席ウィンドウ下降スイッチをクリックします。

  5. しばらくしてから、slexPowerWindowExample/passenger_switch/Normal ブロックの運転席ウィンドウ下降スイッチをオフにします。

  6. ウィンドウがウィンドウ枠の下部に到達すると、シミュレーションを停止します。

  7. armature_current スコープ ウィンドウを拡大して離散化された外観を確認します。

通信プロトコル

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

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

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

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

  • 制御スイッチを表すプラント モデル

  • 信号調整コンポーネントを含むデータ収集サブシステム

  • 物理スイッチからのコマンドを論理コマンドにマップするための制御モジュール

  • 車両のデータ バスにイベントを送る CAN モジュール

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

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

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

  1. コントローラーのサンプルレートを表示します。Simulink エディターの [デバッグ] タブで、[情報のオーバーレイ] 、 [サンプル時間] 、 [色] を選択します。コントローラーが一定のサンプル レートで動作することを確認します。

  2. 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.

関連する例

詳細