ドキュメンテーション センター

  • 評価版
  • 製品アップデート

このページは前リリースの情報です。該当の英語のページはこのリリースで更新されています。このリリースの英語のドキュメンテーションを参照するには、言語設定を United States に変更してください。

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

MATLAB および Simulink の製品ファミリーは、初期仕様からコード生成までの組み込み制御設計のためのモデルベース開発をサポートする一連の多目的ツールで構成されています。

現在の工学システムの複雑さだけでなくその設計チームの複雑さも管理するために、厳密で、あいまいさのない、一貫した仕様に体系的に到達するための構造化解析手法が使用されています。

このような状況において、MATLAB および Simulink の製品ファミリーを使用すると、一般的なコンピューター支援システム/ソフトウェア エンジニアリング (CASE) ツールを使用した場合よりも実際の実装により近いシステム設計をサポートする実行可能な仕様を提供できます。

この例では、MathWorks ツール セットとモデルベース開発プロセスを使用して、構想から実装に至る方法を示します。さらに、この例では、モデルをシステムのドキュメンテーションにリンクする方法を示します。

要件

最近では、自動車で、たとえば、ウィンドウやサンルーフの開閉、ミラー/ヘッドライトの調節、ドアのロックおよびロック解除を制御するために電子工学が使用されています。こうしたシステムは、故障により、危険な状況、場合によっては生命に関わる状況が発生する可能性があるため、厳しい動作制約を受けています。したがって、開発前に慎重な設計と解析が必須です。

この例題では、自動車のパワー ウィンドウ システムの特に助手席のウィンドウに注目してみましょう。このシステムの重要な側面は、ウィンドウを閉めるときに物体に対して 100 N を超える力を及ぼすことができないことです。次を参照してください。

このような物体が検出されると、ウィンドウは約 10 cm だけ下げられます。

より正式には、制御のための量的要件を次のように記述できます。

  • ウィンドウは 4 秒以内に完全に開かれ、完全に閉じられる必要があります。

  • up または down コマンドが最低 200 ミリ秒間、最大 1 秒間発行された場合、それぞれウィンドウは完全に開かれるか、閉じられる必要があります。

  • コマンドが発行されてから 200 ミリ秒後にウィンドウが動き始める必要があります。

  • 物体が存在する場合に検出する力は、100 N 未満である必要があります。

  • 物体が存在する場合、ウィンドウは約 10 cm だけ下げられる必要があります。

高水準離散イベント制御仕様

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

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

離散イベント制御は、状態遷移図の概念を階層と並列性で拡張する Stateflow モデルです。助手席コマンドによる状態変化は、アクティブな運転席コマンドなしに相当する "スーパー ステート" でカプセル化されることに注意してください。

ここでは、助手席のウィンドウの制御を検討します。このウィンドウは、助手席または運転席のいずれかから昇降できます。このモデルには、ダブルクリックすることで手動操作できるスイッチとしてこの制御入力が含まれています。

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

1) 助手席の入力は、3 つの要素をもつベクトルで構成されています。

  • neutral: 助手席の制御スイッチは押されていません。

  • up: 助手席の制御スイッチが up 信号を生成しています。

  • down: 助手席の制御スイッチが down 信号を生成しています。

2) 運転席の入力

  • neutral: 運転席の制御スイッチは押されていません。

  • up: 運転席の制御スイッチが up 信号を生成しています。

  • down: 運転席の制御スイッチが down 信号を生成しています。

3) ウィンドウ枠の上部または下部に達しているかどうか

  • 0: ウィンドウは上部または下部との間で自由に動いています。

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

4) ウィンドウとウィンドウ枠の間に障害物が存在するかどうか

  • 0: ウィンドウは上部または下部との間で自由に動いています。

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

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

     up    down neutral        up    down
------- ------- ------- | ------- -------
      0       0       1 |       0       0
      0       1       0 |       0       1
      1       0       0 |       1       0
      1       1       1 |       0       0

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

ウィンドウの上昇

ステート マシンの動作を確認するには、まず、シミュレーションを実行し、次に、助手席ウィンドウ上昇スイッチをダブルクリックします。

このスイッチが 1 秒より長く押された場合、上昇スイッチが離されるまで (あるいは、ウィンドウ枠の上部に達し、endstop イベントが生成されるまで) ウィンドウは上昇します。

ウィンドウの自動上昇

助手席ウィンドウ上昇スイッチが短時間 (1 秒未満) 押された場合、auto-up がアクティブになり、ウィンドウは上昇し続けます。最終的に、ウィンドウはウィンドウ枠の上部に達し、ステート マシンを neutral ステートに戻す endstop イベントが生成されます。

運転席側の優先

助手席ウィンドウ用の運転席スイッチは、運転席コマンドよりも優先されます。ステート マシンの動作を確認するには、まず、シミュレーションを実行し、次に、助手席ウィンドウ上昇スイッチをダブルクリックしてシステムを passenger up ステートに遷移します。

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

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

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

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

次のサンプル時に、ステート マシンは emergencyDown ステートに遷移してウィンドウを数インチ下げます。正確な距離は、ステート マシンが emergencyDown ステートにある時間に依存しますが、これは次の解析フェーズの一部です。

運転席ウィンドウまたは助手席ウィンドウのスイッチのいずれかがアクティブなままである場合、emergency ステートから外れた後、次のサンプル時に、ステート マシンは up または down ステートに遷移することに注意してください。障害物スイッチがアクティブなままである場合も、次のサンプル時に emergency ステートが再度アクティブになります。

制御サブシステムの検証

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

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

Simulink Verification and Validation™ を使用して、パワー ウィンドウ コントローラーに次のテストを適用してみましょう。

                    step
                0 1 2 3 4 5 6
-----------------------------
passenger up    0 0 0 0 0 0 0
passenger down  0 0 0 1 0 1 1
driver up       0 0 1 0 1 0 1
driver down     0 1 0 0 1 1 0

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

open_system('powerwindow_cv')

テストを生成し、Simulink Verification and Validation カバレッジ レポートを作成するコマンドは次のとおりです。

  • カバレッジ結果を保持するテスト オブジェクトを作成します。 testObj1 = cvtest('powerwindow_cv', 'first_test', 'load firsttest')

  • システムを 7 秒間シミュレートします。 [dataObj1,T,X,Y]=cvsim(testObj1,[0 7])

  • カバレッジ データを含む HTML レポートを作成し、開きます。 cvhtml('powerwindow_cv report',dataObj1)

前述のコマンドを使用してカバレッジ レポートを作成できます。

レポート内の結果により、次のことがわかります。

実行したテストによって、"driver neutral, up, down map" ブロックからの判定結果の 100% が処理されているのに対して、"passenger neutral, up, down map" ブロックの判定結果の 50% しかテストによって処理されていません。また、"endstop" および "obstacle" ブロックのカバー率は、その判定結果の 50% です。

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

離散イベント制御を設計および検証したら、これを連続時間プラント動作に結合できます。そのためには、まず、連続プラント動作に接続する必要がある端子に接続する初期入力/出力ブロックを削除します。

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

  • Stateflow チャートが windowUp を生成する場合、入力は 1 です。

  • Stateflow チャートが windowDown を生成する場合、入力は -1 です。

  • そうでない場合、入力は 0 です。

このフェーズにより、離散イベント ステート動作と、そのサンプルレート、ウィンドウの動きの連続動作間の相互作用の解析が可能になります。ウィンドウ枠の上部と下部、つまり、endStop イベントと、障害物が存在する場合のイベント、つまり、obstacle を生成するために設定されたしきい値があります。

シミュレーション前に、連続時間ソルバーを選択する必要があります。[シミュレーション] メニューから [モデル コンフィギュレーション パラメーター] を選択します。[コンフィギュレーション パラメーター] ウィンドウで [ソルバー] を選択します。ソルバー パラメーターを ode3 (Bogacki-Shampine) ソルバーに変更できます。

あるシステムの構造化解析の結果、そのシステムの機能的分解が行われ、システム信号の仕様を含むデータ ディクショナリと、タイミング制約が作成されます。もう 1 つの側面は実装アーキテクチャですが、ここでは説明しません。

アクティビティ図

アクティビティ図は、仕様をグラフィカルにキャプチャし、システム操作を理解する手段です。階層構造により、大規模なシステムでも簡単に解析できます。トップレベルでは、"コンテキスト図" がシステム環境と、検討中のシステムとの相互作用を (i) データ交換、(ii) 制御操作の観点から記述します。次に、システムは、プロセスおよび制御仕様 (CSPEC と呼ばれます) を含むアクティビティ図に分解されます。プロセスは階層分解を次のように誘導します。各プロセスは、別のアクティビティ図またはプリミティブ仕様 (PSPEC と呼ばれます) によって指定されます。PSPEC は、Simulink ブロック図など、形式的なセマンティクスによる多数の表現で与えることができます。

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

コンテキスト図: POWER WINDOW SYSTEM

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

アクティビティ図のようになるように、Simulink モデルを再配置しましょう。次のことを行います。

  • プラント動作を 1 つのサブシステムに結合します。

  • 運転席および助手席のスイッチを 2 つのサブシステムに結合します。

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

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

  • コンテキスト図用にサイズ変更します。

open_system('powerwindow01')

これで、下に示すアクティビティ図を使用して、コンテキスト図のパワー ウィンドウ コントローラーを部分に分割できるようになりました。コンテキスト図に存在する入力および出力信号は、その発信元を簡単にたどれるように、ここでも再度示されています。

AD 1: POWER WINDOW CONTROL

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

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

運転席および助手席のコマンドについて正しい操作を確認できるように、データ検証機能が追加されました (たとえば、ウィンドウが上部に到達すると、up コマンドはブロックされる必要があります)。各検証プロセスは、新しいサブシステムに分解できます。運転席のコマンドの検証を見てみましょう (助手席のコマンドの検証も同様です)。まず、up コマンドを実行できるか、down コマンドを実行できるかをチェックする必要があります。down コマンドが許可されるのは、ウィンドウが完全に開かれていない場合だけです。up コマンドが許可されるのは、ウィンドウが完全に閉じられておらず、物体が検出されない場合だけです。3 番目のプロセスでは、3 つのコマンド (neutral、up、down) のうちの 1 つのみがコントローラーに送信されることを確認します。実際の実装では、up と down の両方が同時に真である可能性もあります (たとえば、スイッチ バウンスの影響のためなど)。

AD 1.1: VALIDATE DRIVER

VALIDATE DRIVER アクティビティ図の各プロセスは、プリミティブであり、PSPEC で指定されています。これらの 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 PASSENGER プロセスの内部は、VALIDATE DRIVER プロセスとまったく同じです。2 つの違いは、入力と出力の違いだけです。VALIDATE PASSENGER は次のとおりです。

AD 1.2: VALIDATE PASSENGER

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)

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

AD 1.3: DETECT OBSTACLE ENDSTOP

CSPEC 1.3: DETECT OBSTACLE ENDSTOP
  RESET = OBSTACLE or ENDSTOP
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)

データ ディクショナリ

機能的分解は、各プロセスをその分解またはプリミティブ仕様 (PSPEC) によって厳密に指定します。さらに、アクティビティ図内の信号も形式的に指定する必要があります。これが、"データ ディクショナリ" の目標です。

データ ディクショナリには、アクティビティ図のいずれかで使用される信号ごとにエントリをもつテーブルが含まれています。

AD0                         POWER WINDOW SYSTEM
--------------------------- ------- ---------- --------- ---------------
DRIVER_COMMAND                 DATA   DISCRETE AGGREGATE NEUTRAL,UP,DOWN
PASSENGER_COMMAND              DATA   DISCRETE AGGREGATE NEUTRAL,UP,DOWN
WINDOW_POSITION                DATA CONTINUOUS      REAL    0 to 0.4 [m]
MOVE_UP                     CONTROL   DISCRETE   BOOLEAN  'TRUE','FALSE'
MOVE_DOWN                   CONTROL   DISCRETE   BOOLEAN  'TRUE','FALSE'
AD1                         POWER WINDOW CONTROLLER
--------------------------- ------- ---------- --------- ---------------
RESET                       CONTROL   DISCRETE   BOOLEAN  'TRUE','FALSE'
VALIDATED_DRIVER_COMMAND    CONTROL   DISCRETE AGGREGATE NEUTRAL,UP,DOWN
VALIDATED_PASSENGER_COMMAND CONTROL   DISCRETE AGGREGATE NEUTRAL,UP,DOWN
OBSTACLE                    CONTROL   DISCRETE   BOOLEAN  'TRUE','FALSE'
ENDSTOP                     CONTROL   DISCRETE   BOOLEAN  'TRUE','FALSE'
AD1.1                       VALIDATE_DRIVER
--------------------------- ------- ---------- --------- ---------------
NEUTRAL                        DATA   DISCRETE   BOOLEAN  'TRUE','FALSE'
UP                             DATA   DISCRETE   BOOLEAN  'TRUE','FALSE'
DOWN                           DATA   DISCRETE   BOOLEAN  'TRUE','FALSE'
CHECKED UP                     DATA   DISCRETE   BOOLEAN  'TRUE','FALSE'
CHECKED DOWN                   DATA   DISCRETE   BOOLEAN  'TRUE','FALSE'
AD1.2                       VALIDATE_PASSENGER
--------------------------- ------- ---------- --------- ---------------
NEUTRAL                        DATA   DISCRETE   BOOLEAN  'TRUE','FALSE'
UP                             DATA   DISCRETE   BOOLEAN  'TRUE','FALSE'
DOWN                           DATA   DISCRETE   BOOLEAN  'TRUE','FALSE'
CHECKED UP                     DATA   DISCRETE   BOOLEAN  'TRUE','FALSE'
CHECKED DOWN                   DATA   DISCRETE   BOOLEAN  'TRUE','FALSE'
AD1.3                       DETECT_OBSTACLE_ENDSTOP
--------------------------- ------- ---------- --------- ---------------
ENDSTOP_MIN                    DATA   CONSTANT      REAL         0.0 [m]
ENDSTOP_MAX                    DATA   CONSTANT      REAL         0.4 [m]
OBSTACLE_MAX                   DATA   CONSTANT      REAL         0.3 [m]

タイミング要件

次に、powerwindow01 を再度開き、position 測定 (m 単位) を開いてウィンドウの動きを表示し、シミュレーションを実行します。

助手席ウィンドウ上昇スイッチをダブルクリックしてウィンドウの上昇を開始します。

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

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

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

この動作を含める前に、まず、以前に含めた連続動作を削除し、パワー エレクトロニクスと多体系で構成されるより詳細なサブシステムを追加します。

open_system('powerwindow02');

次にこれらを詳しく見てみましょう。

パワー エレクトロニクス

離散イベント コントローラーによって生成された制御信号は、ウィンドウを動かす DC モーターを駆動するのに十分強力になるように「増幅」する必要があります。

これは、増幅モジュールによってモデル化されます。これは、スイッチが DC モーターをバッテリー電圧または接地のいずれかに接続することを示しています。バッテリーを逆に接続することによって、負の電圧が得られ、ウィンドウを昇降したり、その位置に留まらせることができます。ウィンドウは常に最大電力で駆動されること、つまり、規定速度を適用するための DC モーター コントローラーが存在しないことに注意してください。

多体系

ウィンドウは、多体系ブロックセットを使用してモデル化されます。

これは、ボディ、ジョイント、アクチュエータなど、非因果的な多体系要素のライブラリで構成されます。ウィンドウモデルは、ウィンドウ ホルダーを垂直方向に動かす次の要素で構成されます。

ウォーム ギア

レバー

ウィンドウ ホルダーを垂直方向に移動します。

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

設計反復

より詳細な実装の重要な影響は、ウィンドウ位置測定が利用できないことです。その代わり、DC モーターの電流が測定され、端部停止の検出と、障害物が存在するかどうかの検出に使用されます。これは、システム設計の次の段階をもたらします。この段階では、制御を解析し、障害物が存在するときに大きすぎる力を実際に発生させないかどうかを分析できます。

最初に設計されたシステムでは、ウィンドウ位置に基づく障害物と端部停止の検出は削除され、電流ベースの実装で置換されました。また、プロセスはコントローラーと位置および力測定に接続されました。つまり、使用されるさまざまな信号を反映するようにデータ ディクショナリを変更する必要があります。

AD0                         POWER WINDOW SYSTEM
--------------------------- ------- ---------- --------- ---------------
ARMATURE_CURRENT               DATA CONTINUOUS       REAL  -20 to 20 [A]
AD1.3                       DETECT_OBSTACLE_ENDSTOP
--------------------------- ------- ---------- --------- ---------------
ABSOLUTE_ARMATURE_CURRENT      DATA CONTINUOUS      REAL     0 to 20 [A]
ENDSTOP_MAX                    DATA   CONSTANT      REAL          15 [A]
OBSTACLE_MAX                   DATA   CONSTANT      REAL         2.5 [A]

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

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

動作中のシステムの幾何学的形状を表示するには、仮想現実の世界を追加し、ブロック上でダブルクリックしてこれを開きます。

open_system('powerwindow03')

スティッフなソルバー、たとえば、TR-BDF2 (陰的ルンゲ・クッタ法) を選択します。

助手席ウィンドウ上昇スイッチをオンに設定し、運転席ウィンドウ上昇スイッチをオフに設定し、シミュレーションを再度実行します。シミュレーション時間で 1 秒未満で、10 ミリ秒を超える初期時間が経過したら (シミュレーション時間は、モデル ウィンドウのステータス バーの右下隅に表示されます)、助手席ウィンドウ上昇スイッチをオフにして、自動上昇動作を開始します。

ウィンドウ ホルダーが垂直方向に移動してウィンドウを閉じ始めることに注目してください。物体に遭遇すると、ウィンドウは下げられます。

運転席ウィンドウ下降スイッチをクリックしてウィンドウを完全に下げます。同様に、初期時間 (1 秒未満のシミュレーション時間) が経過したら、運転席ウィンドウ下降スイッチをオフにして、自動下降動作を開始します。

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

次に、position 測定 (m 単位) と armature current (Ia) 測定 (A 単位) を見てみましょう。

通常の動作中の電機子電流トランジェントの絶対値は 10 A を超えないことに注目してください。ウィンドウを上昇させるために必要な電機子電流の絶対値が 2.5 A (実際、-2.5 A 未満) を超えると、障害物が検出されます。通常の動作中、この値は約 2 A です。これをよく見るためには、おそらく拡大する必要があります。電機子電流の絶対値が 15 A を超えると、ウィンドウの端部停止が検出されます。

通常動作中の電機子電流の変化の原因は、ジョイントの速度と位置を検出することと、ウィンドウ固有の係数を適用することによって含められる摩擦です。

この目的のためにルックアップ テーブルが使用され、制御のロバスト性を評価できるようにノイズが付加されます。

制御則の評価

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

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

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

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

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

現実的な電機子測定

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

これらを含めるには、まず、理想的な測定を削除します。次に、電圧測定に基づいて電流が導出される信号調整ブロックを含むより現実的な測定を追加します。

この電圧は、特定のビット数に基づいて離散化するアナログ デジタル コンバーター (ADC) の範囲内です。結果の値は、使用される抵抗器の値と、選択された ADC の範囲に基づいて、スケーリングする必要があります。

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

同じシナリオを検討します。

  • 助手席ウィンドウ上昇スイッチを設定します。

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

  • しばらくしてから、助手席ウィンドウ上昇スイッチをオフにします。

  • ウィンドウが下げられたら、運転席ウィンドウ下降スイッチをクリックします。

  • しばらくしてから、運転席ウィンドウ下降スイッチをオフにします。

  • ウィンドウがウィンドウ枠の下部に到達したら、シミュレーションを停止します。

拡大して電機子電流が離散化された外観をもつようになったことに注目してください。

モデルの再構成

図が乱れないように、設計したモデルはサブシステムを使用して再構成されています。

  • まず、DAQ サブシステムを折りたたみます。

  • 次に、アクチュエータおよびプラント サブシステムを折りたたみます。

通信プロトコル

Stateflow 出力部と同様に、入力イベントは、ハードウェアによって、この場合は、ドアおよびセンター コントロール パネルにあるウィンドウ制御スイッチによって生成される必要があります。こうしたイベントは、ローカル プロセッサによって生成されてから、CAN バスによってウィンドウ コントローラーに伝達されます。

open_system('powerwindow05')

これらの現象を含めるには、まず、理想的な入力を削除し、CAN バスからの入力を追加します。次に、イベントを生成するスイッチ コンポーネントを追加し、これらを CAN バス上に配置します。スイッチ サブシステムを開くと、

ウィンドウ制御システムに非常によく似た構造に気付くでしょう。この場合も同様に、制御スイッチを表すプラント モデルと、

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

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

車両のデータ バスにイベントを送る CAN モジュールがあります。

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

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

設計したコントローラーのコードを生成するには、

まず、コントローラーをオンにしてサンプルレートをチェックします。これを行うには、[情報表示] メニューの [サンプル時間]、[色] を選択します。これにより、コントローラーが一定のサンプルレートで動作することがわかります。

次に、ウィンドウ制御モジュールで右マウスボタンをクリックし、[C/C++ コード]、[このサブシステムをビルド] を選択して、サブシステムのリアルタイム コードを作成します。

参照

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

この情報は役に立ちましたか?