Main Content

电动车窗

汽车使用电子设备来控制各种操作,例如:

  • 打开和关闭车窗和天窗

  • 调整后视镜和前灯

  • 车门上锁和开锁

这些系统具有严格的操作约束。一旦出现故障,可能会发生危险,甚至威胁人身安全。因此,必须在部署之前进行仔细的设计和分析。

本示例主要介绍汽车电动车窗控制系统的设计,尤其是乘客侧车窗。此系统的关键是:当车窗关闭时,它不能对窗口中存在的物体施加超过 100 N 的作用力。当系统检测到存在此类物体时,必须将车窗降下约 10 厘米。

作为设计过程的一部分,此示例需要考虑:

  • 车窗控制系统的定量要求,例如时间和作用力的要求

  • 在活动图中捕获的系统要求

  • 活动图中使用的信号的数据定义

此示例包含的设计过程的其他方面包括:

  • 管理系统组件

  • 构建模型

  • 验证系统仿真结果

  • 生成代码

MATLAB® 和 Simulink® 支持采用基于模型的设计来完成嵌入式控制系统设计(从初始设定到代码生成)。电动车窗控制工程说明如何使用 MathWorks® 工具和基于模型的设计过程,完成汽车电动车窗控制系统的整个设计(从概念到实现)。它使用工程来组织文件和其他模型组件。

电动车窗控制工程

此示例说明如何使用工程为汽车的电动车窗系统建模。该工程使用基于模型的设计和以下大型建模方法。

  • Model 模块,用于将层次结构分成若干单独的模型。

  • Variant Subsystem 模块,用于对设计选择项建模以及在不同设计选择项之间切换。

  • 库,用于捕获算法以在可变子系统中重用。

  • 工程,用于管理系统开发所需的文件。

设计需求

在此示例中,以汽车的乘客侧电动车窗系统为例。在关闭车窗时,此系统不能对物体施加 100 N 以上的作用力。

当检测到存在此类物体时,模型必须将车窗降下约 10 厘米。

有关设计需求的详细信息,请参阅电动车窗

浏览工程

通过目测工程,您可以看到用于组织该示例的功能。这些功能用于组织工程:

  • 文件夹

  • 文件分类

  • 快捷方式

文件夹

工程组织到以下文件夹中:

  • configureModel - 控制主系统模型变体配置的 MATLAB® 文件

  • data - 工程所需的图像

  • hmi - 以动画形式显示电动车窗响应的文件

  • model - 主系统模型、控制器模型、控制器测试模型以及支持这些模型的库

  • task - 仿真不同模型配置的模型并为控制器生成覆盖率报告的 MATLAB 文件

  • utilities - MATLAB 文件,用于初始化模型、生成电子表格输入、向生成的电子表格添加数据,以及在启动和关闭时管理工程环境

文件分类

“工程”中的“文件”在“标签”窗格中显示有不同的分类。每个标签都描述了文件在工程主体中所起的特定作用。

  • Configuration - 配置工程或模型的文件。

  • PrjConfig - 通过在启动时将文件添加到路径中并在关闭时删除这些文件来配置工程的文件

  • DesignConfig - 确定在给定时间哪个模型配置处于活动状态的文件

  • Design - 主系统模型及其引用的控制模型

  • DesignSupport - 库、数据和模型仿真等文件

  • Simulation - 仿真特定配置的模型的文件

  • Test - 控制覆盖率、控制交互和测试框架模型

  • Visualization - 以动画方式显示电动车窗运动的文件

快捷方式

工程快捷方式可用于快速访问最常用的工程文件。一些快捷方式包含常规任务,例如在启动时将工程添加到路径中,以及在关闭时将其删除。此外,工程快捷方式组有助于组织快捷方式。

  • 交互式测试 - 用于控制器交互式测试的文件

  • 主模型 - 顶层 Simulink 模型的文件

  • 模型覆盖率 - 用于控制器模型覆盖率的文件

  • 仿真 - 用于模型变体配置仿真的文件

浏览工程中的 Simulink 模型

此工程的 Simulink 模型位于 model 文件夹中。

  • 主要系统模型

  • 用于测试的模型

主要系统模型

主系统模型是 slexPowerWindowExample。此模型由 driver_switchpassenger_switch 子系统模块组成,这些模块可生成 power_window_control_system 模块的输入。power_window_control_system 模块可验证乘客和驾驶员输入的状态。此模块还可确定障碍物是否会阻挡车窗的路径。引用的控制器会生成车窗运动命令信号,该信号发送到车窗系统的活动变体。window_system 模块输出是对控制系统模块的反馈。

为了可视化仿真结果,仿真数据检查器会记录输出数据,而 Simulink 3D Animation™ 会生成窗口运动的动画。

模型变体

此工程中的主系统模型使用 Variant Subsystem 模块,以使一个子系统中有多个实现。您可以在仿真之前以编程方式更改处于活动状态的实现。主模型包含四个 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 快捷方式对此变体配置进行仿真。此快捷方式仅激活与此模型配置对应的可变子系统。由于此模型没有考虑到电效应,因此记录的唯一输出是位置。仿真数据检查器显示记录的位置数据。

电动车窗控制器和详细的被控对象模型

此模型变体显示更详细的被控对象模型,该模型包括电气和机械领域的电效应,用于验证车窗施加在被卡物体上的力不超出 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 许可证。您可以使用 SimCANCommunication 快捷方式在运行 Windows 操作系统的计算机上对此变体配置进行仿真。

用于测试的模型

要测试控制电动车窗的状态机,您可以运行用于测试的工程快捷方式。用于测试控制器的模型快捷方式包括:

  • InteractiveExample

  • CoverageExample

  • IncreaseCoverageExample

InteractiveExample

此模型快捷方式可打开模型 slexPowerWindowCntlInteract。此模型包含电动车窗控制器,后者是一个状态机。此模型还包含通过 Manual Switch 模块选择的控制器的输入。

电动车窗控制器有四个外部输入:

Passenger Input 输入由一个包含以下三个元素的向量组成:

  • neutral:乘客控制开关未按下。

  • up:乘客控制开关生成上移信号。

  • down:乘客控制开关生成下移信号。

Driver Input 输入由一个包含以下三个元素的向量组成:

  • neutral:司机控制开关未按下。

  • up:司机控制开关生成上移信号。

  • down:司机控制开关生成下移信号。

Window Frame Endstops 输入由一个包含以下两个元素的向量组成:

  • 0:车窗在顶部和底部之间自由移动。

  • 1:车窗由于物理限制停在顶部或底部。

Obstacle Present 输入由一个包含以下两个元素的向量组成:

  • 0:车窗在顶部和底部之间自由移动

  • 1:车窗窗框内有障碍物

通过仿真模型并利用 Manual Switch 模块选择所需的输入组合,您可以交互方式测试控制器。在选择输入后,您可以根据特定输入集的期望结果来验证内部控制器状态和控制器输出。

CoverageExample

此模型快捷方式可打开模型 slexPowerWindowCntlCoverage。此模型包含电动车窗控制器,后者是一个状态机。此模型还包含通过 Repeating Sequence 模块选择的控制器输入。

您可以使用 Simulink Coverage 模型覆盖率工具来验证车窗的离散事件控制。模型覆盖率工具确定模型测试用例执行到的控制器条件分支的范围。该工具用于评估在给定测试用例的情况下,离散事件控制中的所有转移是否都已覆盖。该工具还用于评估实现特定转移的某个条件的所有子句是否都为真。一项状态转移可以通过多个子句来实现,例如,当经过 100 个计时单位后或到达停止位时,就会从 emergency 状态回到 neutral 状态。

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 秒之内完全打开和完全关闭。

  • 如果发出上移命令的时间在 200 毫秒到 1 秒之间,车窗必须完全打开。如果发出下移命令的时间在 200 毫秒到 1 秒之间,车窗必须完全关闭。

  • 在发出命令之后的 200 毫秒内,车窗必须开始移动。

  • 用来检测是否存在物体的作用力小于 100 N。

  • 关闭车窗时,如果有物体阻挡,必须停止关闭并将车窗降低大约 10 厘米。

在活动图和环境图中捕获要求

活动图可以帮助您以图形方式捕获设定并理解系统的运作。层次结构可以帮助您进行分析,即使是大型系统。顶层的环境图描述系统环境以及它与被研究系统在数据交换和控制操作方面的交互。然后,您可以将系统分解为包含过程和控制设定 (CSPEC) 的活动图。

这些过程指导您如何分解层次结构。您可以使用另一个活动图或原始设定 (PSPEC) 指定每个过程。您可以通过多种基于形式语义的表示方法(例如 Simulink 模块图)来指定 PSPEC。此外,环境图还以图形方式捕获系统操作的环境。使用设定的数据定义。

环境图:电动车窗系统

下图表示电动车窗控制系统的环境图。方框用于捕获环境,在本示例中包括司机、乘客和车窗。司机和乘客都可以发出命令,使车窗向上和向下移动。控制器用于推断要发送给车窗作动器的正确命令(例如,司机命令的优先级高于乘客命令)。此外,该图还监视车窗控制系统的状态,以确定车窗何时完全打开和关闭,并检测车窗玻璃与窗框之间是否存在物体。

圆形(也称为圆泡)表示电动车窗控制器。圆形是过程的图形化表示。各过程捕获从输入数据到输出数据的转换。原始过程也可能生成这一转换。CSPEC 通常由组合逻辑或时序逻辑构成,用于根据输入控制推断输出控制信号。

要了解在 Simulink 环境中的实现,请参阅实现上下文图:电动车窗系统

电动车窗系统数据定义

信号信息类型连续/
离散
数据类型

DRIVER_COMMAND

数据

离散

聚合

Neutral, up, down

PASSENGER_COMMAND

数据

离散

聚合

Neutral, up, down

WINDOW_POSITION

数据

连续

实数

0 到 0.4 m

MOVE_UP

控制

离散

布尔

'True', 'False'

MOVE_DOWN

控制

离散

布尔

'True', 'False'

活动图:电动车窗控制系统

电动车窗控制系统包括三个过程和一个 CSPEC。其中两个过程负责验证司机和乘客输入,以确保他们的输入在给定的系统状态下有意义。例如,如果车窗已完全打开,则 MOVE DOWN 命令没有意义。第三个过程检测车窗是否完全打开或完全关闭,以及是否存在物体。CSPEC 接收控制信号并推断车窗是向上还是向下移动(例如,如果存在物体,车窗将向下移动大约一秒钟,或在到达停止位时停止)。

电动车窗控制数据定义

信号信息类型连续/
离散
数据类型

DRIVER_COMMAND

数据

离散

聚合

Neutral, up, down

PASSENGER_COMMAND

数据

离散

聚合

Neutral, up, down

WINDOW_POSITION

数据

连续

实数

0 到 0.4 m

MOVE_UP

控制

离散

布尔

'True', 'False'

MOVE_DOWN

控制

离散

布尔

'True', 'False'

活动图:验证司机的输入

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)

验证司机数据定义

信号信息类型连续/
离散
数据类型

DRIVER_COMMAND

数据

离散

聚合

Neutral, up, down

PASSENGER_COMMAND

数据

离散

聚合

Neutral, up, down

WINDOW_POSITION

数据

连续

实数

0 到 0.4 m

MOVE_UP

控制

离散

布尔

'True', 'False'

MOVE_DOWN

控制

离散

布尔

'True', 'False'

活动图:验证乘客的输入

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 环境中的实现,请参阅活动图:验证乘客的输入

验证乘客数据定义

信号信息类型连续/
离散
数据类型

NEUTRAL

数据

离散

布尔

'True', 'False'

UP

数据

离散

布尔

'True', 'False'

DOWN

数据

离散

布尔

'True', 'False'

CHECKED_UP

数据

离散

布尔

'True', 'False'

CHECKED_DOWN

数据

离散

布尔

'True', 'False'

活动图:检测障碍物和停止位

POWER WINDOW CONTROL 活动图中的第三个过程检测是否存在障碍物,或者车窗何时到达顶部或底部 (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 环境中的实现,请参阅活动图:检测障碍物和停止位

检测障碍物停止位数据定义

信号信息类型连续/
离散
数据类型

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 是一个离散事件控制器,它以给定的采样率运行。

在此实现中,打开 power window control 子系统,可以看到具有离散事件控制的 Stateflow 图构成了 CSPEC,由右下角的倾斜粗条形表示。detect_obstacle_endstop 子系统封装了阈值检测机制。

离散事件控制是一个 Stateflow 模型,它利用层次结构和并行机制扩展了状态转移图概念。因乘客命令而产生的状态改变封装在父状态中,该状态与活动状态的司机命令不相关。

以乘客侧车窗的控制为例。乘客或司机都可以使车窗向上和向下移动。

此状态机包含电动车窗控制系统的基本状态:up、auto-up、down、auto-down、rest 和 emergency。

交互式测试

控制输入

slexPowerWindowCntlInteract 模型中以开关的形式表示此控制输入。双击这些开关可以手动操作它们。

通过运行输入测试向量并检查它是否达到所需的内部状态并生成输出,测试控制电动车窗的状态机。电动车窗具有以下外部输入:

  • 乘客输入

  • 司机输入

  • 车窗上移或下移

  • 窗口中存在障碍物

每个输入都包含一个以这些输入为值的向量。

乘客输入

元素描述
neutral

乘客控制开关未按下。

up

乘客控制开关生成上移信号。

down

乘客控制开关生成下移信号。

司机输入

元素描述
neutral

司机控制开关未按下。

up

司机控制开关生成上移信号。

down

司机控制开关生成下移信号。

车窗上移或下移

元素描述
0

车窗在顶部和底部之间自由移动。

1

车窗由于物理限制停在顶部或底部。

窗口中存在障碍物

元素描述
0

车窗在顶部和底部之间自由移动。

1

窗口中存在障碍物。

根据下表映射上移和下移信号,生成乘客和司机输入信号:

输入输出
updownupdownneutral

0

0

0

0

1

0

1

0

1

0

1

0

1

0

0

1

1

0

0

1

这些输入根据按下电动车窗控制开关生成的 updown 事件显式生成 neutral 事件。这些输入以真值表形式输入到 passenger neutral, up, down map 和 driver neutral, up, down map 中。

用例 1:车窗上移

要观察状态机的行为,请执行以下操作:

  1. 打开 slexPowerWindowCntlInteract 模型。

  2. 运行仿真,然后双击 passenger up 开关。

    如果按住物理车窗开关超过一秒钟,车窗就会上移,直到松开 up 开关(或到达窗框顶部并生成 endstop 事件)为止。

  3. 双击选定的 passenger up 开关以松开此开关。

  4. 对模型进行仿真。

    设置 endstop 开关将生成 endstop 事件。

用例 2:车窗自动上移

如果短时间(少于一秒)按住物理乘客侧车窗上移开关,软件将激活 auto-up 行为,车窗将继续上移。

  1. 短时间(少于一秒)按住物理乘客侧车窗上移开关。

    最后,车窗达到窗框顶部,软件生成 endstop 事件。此事件将状态机恢复到 neutral 状态。

  2. 对模型进行仿真。

用例 3:司机侧优先

乘客侧车窗的司机开关优先于司机命令。要观察这种情况下的状态机行为,请执行以下操作:

  1. 运行仿真,然后通过双击 passenger up 开关,使系统进入 passenger up 状态。

  2. 双击 driver down 开关。

  3. 对模型进行仿真。

  4. 请注意状态机如何移到司机控制部分,生成车窗下移输出,而不是车窗上移输出。

  5. 双击司机 driver up 控制开关。双击 driver down 开关。

    进入 driver window up 状态,再次生成车窗上移输出,即 windowUp = 1

  6. 要观察车窗与窗框之间存在物体时的状态行为,请双击 obstacle 开关。

  7. 对模型进行仿真。

    在下一个采样时间,状态机移动到 emergencyDown 状态,将车窗降下几英寸。软件将车窗降下多少取决于状态机处于 emergencyDown 状态的时间长短。此行为是下一个分析阶段的一部分。

    如果司机或乘客车窗开关仍处于活动状态,状态机将在退出 emergency 状态后的下一个采样时间立即进入 up 或 down 状态。如果 obstacle 开关也处于活动状态,软件将在下一个采样时间再次激活 emergency 状态。

模型覆盖率

验证控制子系统

使用模型覆盖率工具验证车窗的离散事件控制。此工具可帮助您确定模型测试用例执行到的控制器条件分支的范围。它可以帮助评估在给定测试用例中,离散事件控制的所有状态转移是否都发生,以及实现特定转移的某个条件的所有子句是否都满足。多个子句可以实现一个状态转移,例如,当经过了 100 个计时单位后或到达停止位时,就会从 emergency 状态回到 neutral 状态。

要实现完全覆盖,对于使用的测试用例,每个子句计算都要涵盖 true 和 false 两种情况。测试用例产生的转移的百分比称为模型覆盖率。模型覆盖率用于衡量一个测试执行模型的全面程度。

使用 Simulink Coverage™ 软件,您可以对电动车窗控制器应用以下测试。

位置
0123456
Passenger up 0000000
Passenger down0001011
Driver up 0010101
Driver down0100110

在此测试中,当时间为 0 时,所有开关都处于非活动状态。在间隔 1 秒的各步中,一个或多个开关的状态发生了改变。例如,1 秒之后,driver down 开关处于活动状态。要自动运行这些输入向量,可将手动开关替换为指定的输入序列。要查看预构造的模型,请执行以下操作:

  1. 打开 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 中,每个工作表为一个输入集。

在此示例中,使用 slexPowerWindowSpreadsheetGeneration 工具函数(它从控制器模型 slexPowerWindowControl 中创建电子表格模板)创建 inputCntlCoverageIncrease.xlsx。在 inputCntlCoverageIncrease.xlsx 中,该函数使用控制器模型中的模块名称作为信号名称。slexPowerWindowSpreadsheetGeneration 定义工作表名称。slexWindowSpreadsheetAddInput 工具函数使用信号数据填充 inputCntlCoverageIncrease.xlsx

这些输入集的工作表名称和描述如下:

工作表名称描述

Logged

slexPowerWindowCntlCoverage 记录的输入

LoggedObstacleOffEndStopOn

slexPowerWindowCntlCoverage 记录的输入,能够到达停止位

LoggedObstacleOnEndStopOff

slexPowerWindowCntlCoverage 记录的输入,窗口存在障碍物

LoggedObstacleOnEndStopOn

slexPowerWindowCntlCoverage 记录的输入,窗口存在障碍物并且能够到达停止位

DriverLoggedPassengerNeutral

slexPowerWindowCntlCoverage 记录的输入,仅针对司机的操作,乘客不执行任何操作

DriverDownPassengerNeutral

司机降下车窗,乘客不执行任何操作

DriverUpPassengerNeutral

司机升起车窗,乘客不执行任何操作

DriverAutoDownPassengerNeutral

司机降下车窗一秒钟(自动下移),乘客不执行任何操作

DriverAutoUpPassengerNeutral

司机升起车窗一秒钟(自动上移),乘客不执行任何操作

PassengerAutoDownDriverNeutral

乘客降下车窗一秒钟(自动下移),司机不执行任何操作

PassengerAutoUpDriverNeutral

乘客升起车窗一秒钟(自动上移),司机不执行任何操作

要自动运行这些输入向量,将离散事件控制的输入替换为使用 inputCntlCoverageIncrease.xlsx 文件的 From Spreadsheet 模块。此文件包含这些输入集。要查看预构造的模型,请执行以下操作:

  1. 打开 slexPowerWindowCntlCoverageIncrease 模型。

  2. 要为多个输入集生成 Simulink Coverage 覆盖率报告,请双击模型中的 Run Coverage 子系统。

    对于 slexPowerWindowCntlCoverageIncrease 模型,该报告显示使用多个输入集成功地将 slexPowerWindowControl 模型的整体覆盖率从 42% 提高到 78%。覆盖率水平低于 100%,因为缺少以下输入集:

    • 乘客上移状态

    • 司机上移和下移状态

    • 乘客自动下移和自动上移状态

使用基于模型的设计创建模型

实现上下文图:电动车窗系统

要查看以环境图形式表示的要求,请参阅环境图:电动车窗系统

创建一个类似于环境图的 Simulink 模型。

  1. 将被控对象行为放入一个子系统。

  2. 创建两个子系统,分别包含司机和乘客的开关。

  3. 添加一个控制机制,方便在存在和不存在物体两种情况之间进行切换。

  4. 将该控件放入一个子系统。

  5. 将新的子系统连接起来。

  6. 要查看此模型的实现,请打开 slexPowerWindowExample 模型。

您可以使用电动车窗控制系统活动图(活动图:电动车窗控制系统)分解环境图中的电动车窗控制器。此图显示了环境图中出现的输入信号和输出信号,以便跟踪它们的来源。

实现电动车窗控制系统

要满足全部要求,电动车窗控制系统必须要验证司机和乘客的输入并检测停止位。

要查看以活动图形式表示的要求,请参阅活动图:电动车窗控制系统

双击 slexPowerWindowExample/power_window_control_system 模块以打开以下子系统:

实现活动图:验证

要查看以活动图形式表示的要求,请参阅活动图:验证司机的输入活动图:验证乘客的输入

活动图添加了针对司机和乘客命令的数据验证功能,以确保操作正确。例如,当车窗到达顶部时,软件将阻止 up 命令。该实现使用新的子系统分解每个验证过程。以司机命令的验证为例(乘客命令的验证大体相同)。检查模型能否根据以下条件执行 updown 命令:

  • 仅在车窗未完全打开时,模型才允许 down 命令。

  • 仅在车窗未完全打开并且未检测到物体时,模型才允许 up 命令。

第三个活动图过程检查软件是否仅向控制器发送三个命令(neutralupdown)之一。在实际的实现中,updown 可以同时为 true(例如,由于开关的弹跳效应)。

在 power_window_control_system 子系统中,validate_driver_state 子系统如下所示:

在 power_window_control_system 子系统中,validate_passenger_state 子系统如下所示:

实现活动图:检测障碍物和停止位

要查看以活动图形式表示的要求,请参阅活动图:检测障碍物和停止位

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 模块以查看以下连续变体。

被控对象建模为二阶微分方程,其输入随每步变化:

  • 当 Stateflow 图生成 windowUp 时,输入为 1。

  • 当 Stateflow 图生成 windowDown 时,输入为 -1。

  • 否则,输入为 0。

此阶段可对离散事件状态行为、采样率以及连续的车窗移动行为之间的交互情况进行分析。可通过以下这些阈值来得出窗框顶部和底部:

  • endStop

  • 存在障碍物时的事件,即 obstacle

  • 其他事件

双击 slexPowerWindowExample 模型的 ower_window_control_system/detect_obstacle_endstop/Continuous/verify_position 模块以查看连续变体。

当您运行 slexPowerWindowContinuous configureModel 实用工具时,模型将使用连续时间求解器 ode23 (Bogacki-Shampine)。

对系统进行结构分析可得到以下内容:

  • 系统的功能分解

  • 包含系统信号细节的数据定义

  • 计时约束

结构分析还可以包括实现架构(不属于本文讨论范围)。

此实现还添加了一个控制机制,方便在存在和不存在物体两种情况之间进行切换。

预期的控制器响应.  要查看车窗移动,请在工程快捷方式中,双击 SimHybridPlantLowOrder。您也可以运行任务 slexPowerWindowContinuousSim

位置示波器显示了控制器的预期结果。在移动 30 厘米之后,模型生成 obstacle 事件,Stateflow 图进入 emergencyDown 状态。在此状态下,输出为 windowDown,直到车窗降低约 10 厘米为止。由于 passenger window up 开关仍处于 on 状态,因此车窗再次开始上移并重复此过程。停止仿真并打开位置示波器,以观察振荡过程。在紧急情况下,离散事件控制将车窗下移大约 10 厘米。

电效应的详细建模

对离散事件控制和连续动态特性进行初步分析之后,您可以使用详细的被控对象模型来评估更真实情况下的执行情况。最好是在电力域(即以电量流的形式)设计这一详细程度级别的模型。有几个用于特定域的 MathWorks 模块集可以帮助您实现此目的。

要将电量流考虑在内,可向 window_system 可变子系统中添加一个更详细的包含电力电子系统和多体系统的变体。

要打开模型并查看更详细的被控对象变体,请在工程中运行 configureModel slexPowerWindowPowerEffects

双击 slexPowerWindowExample 模型的 window_system/Power Effects - Visualization/detailed_window_system 模块。

电力电子元件子系统.  该模型必须将离散事件控制器生成的控制信号放大到足够强的程度,以驱动直流电机移动车窗。

放大模块负责对此行为进行建模。它们显示开关要么将直流电机连接到电池电压,要么连接到地线。通过反接电池,系统生成负电压,车窗可以上移、下移或静止不动。车窗始终以最大功率驱动。换言之,没有直流电机控制器应用预定的速度。

要查看实现,请双击 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 模块表示车身、接头和作动器。车窗模型包括:

  • 一个蜗轮

  • 一个沿垂直方向移动车窗玻璃托架的操作杆

下图显示了机械零部件如何移动。

设计迭代.  这一更详细的实现有一个重要特点,即没有车窗位置测量值。实际上,该模型需要通过测量直流电机电流并使用测量值来检测停止位以及是否存在障碍物。系统设计的下一阶段是对控制进行分析,确保它在存在障碍物时不会产生过大的作用力。

在原来的系统中,设计删除了基于车窗位置的障碍物和停止位检测,将其替换为基于电流的实现。它还将该过程关联到控制器以及车窗位置和作用力测量值。要反映使用的不同信号,您必须修改数据定义。此外请注意,由于电效应的原因,现在的单位是安。

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)

下表列出了环境图:Power Window System 数据定义中使用的其他信号。

环境图:Power Window System 数据定义变化

信号信息类型连续/
离散
数据类型

ARMATURE_CURRENT

数据

连续

实数

–20 到 20 A

下表列出了活动图:检测障碍物停止位数据定义

活动图:Detect Obstacle Endstop 数据定义变化

信号信息类型连续/常量
数据类型

ABSOLUTE_ARMATURE_CURRENT

数据

连续

实数

0 到 20 A

ENDSTOP_MAX

数据

常量

实数

15A

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 模块。

控制规则评估

理想的连续被控对象须能访问车窗位置以生成 endStopobstacle 事件。在更符合实际的实现中,模型必须从可访问的物理变量中生成这些事件。对于电动车窗系统,此物理变量通常是驱动涡轮的直流电机的电枢电流 Ia

当车窗移动时,此电流的值约为 2 A。当您开启车窗开关时,模型使用大约为 10 A 的瞬变电流。当电流超过 15 A 时,模型激活停止位检测。不管输入电压为正还是为负,当电机的角速度保持在几乎为 0 时,模型将使用此电流。

在这一系统设置中,检测是否存在物体更加困难。因为出于安全方面的考虑,车窗作用力被限制为小于 100 N,所以一个远低于 10 A 的电枢电流就应当能够检测到物体。但是,此行为与正常操作时出现的瞬变电流值发生冲突。

因此需要实现一个控制规则,在出现瞬变电流值时禁用物体检测。这样,当系统检测到电枢电流高于 2 A 时,它会认为窗口存在物体,并进入离散事件控制的 emergencyDown 状态。打开作用力示波器窗口(测量值以牛顿为单位),检查当存在物体时,车窗施加的作用力始终小于 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 模块中,将 passenger up 开关设置为 on。

  3. slexPowerWindowExample 模型的 driver_switch/Normal 模块中,将 driver up 开关设置为 off。

  4. 对模型进行仿真。

  5. 当仿真时间介于 10 毫秒和 1 秒之间时,关闭 slexPowerWindowExample/passenger_switch/Normal 模块的 passenger up 开关,以启动 auto-up 行为。

  6. 观察车窗玻璃托架如何开始垂直移动以关闭车窗。当模型遇到物体时,会将车窗向下移动。

  7. 双击 slexPowerWindowExample 模型的 passenger_switch/Normal 模块中的 driver down 开关,将车窗完全降下,然后仿真该模型。在此模块中,在不到一秒的仿真时间内关闭 driver down 开关,以激活 auto-down 行为。

  8. 当车窗到达窗框底部时,停止仿真。

  9. 查看位置测量值(以米为单位)和电枢电流 (Ia) 测量值(以安为单位)。

    注意

    在正常行为期间,瞬变电枢电流的绝对值不超过 10 A。当将车窗上移所需的电枢电流的绝对值高于 2.5 A 时(实际为低于 –2.5 A),表示模型检测到障碍物。在正常操作中,此值约为 2 A。您可能需要放大示波器窗口才能看到此测量值。当电枢电流的绝对值高于 15 A 时,表示模型检测到车窗停止位。

    正常操作时,电枢电流的变化是摩擦力造成的,摩擦力是通过感知轴节的速度和位置并应用车窗特定系数而得出的。

实际的电枢电流测量值

电动车窗控制系统中使用的电枢电流是一个理想值,该值是通过作动器模型而得出的。在更为真实的实际情形中,数据采集组件必须测量此电流值。

要使用数据采集组件,请向 window_system 可变子系统中添加更符合实际情形的测量变体。这个实际情形测量变体包含一个信号调节模块,它基于电压测量值计算出电流。

要打开模型并配置符合实际情形的测量系统,请在工程中运行 configureModel 任务 slexPowerWindowRealisticArmature

要查看 Realistic Armature - Communications Protocol 模块的内容,请双击 SlexPowerWindowExample 模型的 window_system/Realistic Armature - Communications Protocol/detailed_window_system_with_DAQ。

测量电压在基于给定的位数进行离散化的模数转换器 (ADC) 的范围内。您必须基于电阻值和 ADC 的范围对得到的值进行定标。

这些运算会作为定点计算包含在模型中。要实现具有给定范围的必要分辨率,必须使用 16 位,而不是 8 位。

研究同一场景:

  1. 在 slexPowerWindowExample/passenger_switch/Normal 模块中,设置 passenger up 开关。

  2. 运行仿真。

  3. 一段时间之后,在 slexPowerWindowExample/passenger_switch/Normal 模块中,关闭 passenger up 开关。

  4. 当车窗降下之后,点击 slexPowerWindowExample/passenger_switch/Normal 模块中的 driver down 开关。

  5. 一段时间之后,关闭 slexPowerWindowExample/passenger_switch/Normal 模块中的 driver down 开关。

  6. 当车窗到达窗框底部时,停止仿真。

  7. 放大 armature_current 示波器窗口,并注意离散化的外观。

通信协议

与电动车窗输出控制项类似,硬件必须生成输入事件。在本例中,硬件是车门和中央控制面板上的车窗控制开关。本地处理器生成这些事件,然后通过 CAN 总线将其传递给车窗控制器。

要考虑这些事件,请添加一个变体,其中包含来自 CAN 总线的输入信号以及生成事件的开关组件(生成的事件通过 CAN 总线发送给 driver switch 和 passenger switch 可变子系统)。要打开模型并配置 CAN 通信协议,请运行 configureModel 任务 slexPowerWindowCommunicationProtocolSim

要查看 switch 子系统的实现,请双击 slexPowerWindowExample/driver_switch/Communication Protocol/driver window control switch 模块。

注意,这一结构与车窗控制系统非常相似,其中包含:

  • 被控对象模型(代表控制开关)

  • 数据采集子系统(包括信号调节组件等内容)

  • 控制模块(将来自物理开关的命令映射到逻辑命令)

  • CAN 模块(将事件发送给车辆数据总线)

您可以像前面描述的阶段一样,添加通信效应(例如使用 CAN 总线的其他系统)和更为实际的因素。这样每阶段都可越来越接近实际地对离散事件控制器进行分析。当您掌握足够多的细节后,可以自动生成适用于任何特定目标平台的控制器代码。

自动生成控制子系统的代码

您可以为设计的控制模型 slexPowerWindowExample 生成代码。

  1. 显示控制器的采样率。在 Simulink 编辑器中,在调试选项卡上,选择叠加信息 > 采样时间 > 颜色。注意控制器按均匀采样率运行。

  2. 右键点击 power_window_control_system 模块并选择 C/C++ 代码 > 编译此子系统

参考资料

Mosterman、Pieter J.、Janos Sztipanovits 和 Sebastian Engell,“Computer-Automated Multiparadigm Modeling in Control Systems Technology”,IEEE Transactions on Control Systems Technology,2004 年第 12 期第 2 卷,223–234 页。

相关示例

详细信息