如何设计ADAS系统功能状态机（二）.docVIP

如何设计ADAS系统功能状态机（二） 1.定义状态 状态定义：明确定义系统中的状态，确保每个状态都是清晰且互斥的。每个状态应该具有明确的含义和行为。 不同的自动驾驶功能可能具有不同的状态机，状态的定义是由功能决定的，系统需要在不同的条件下正确地执行相应的行为和功能。同时，状态机的设计原理也应该为系统的扩展和维护提供了便利，使得系统能够适应不断变化的需求和环境；比如在NOP功能设计时，应考虑到如何与LCC/ACC等功能进行切换。 L0的ADAS功能，比如FCW/LDW/BSD等等基本不涉及车辆控制，仅起到预警作用。其状态定义也较为简单，可以分为以下几个状态： OFF:系统关闭，未进行工作。 Standby：系统满足运行条件，正在待机。 Warning：符合预警触发条件，正在报警。 Inhibit：预警被用户抑制。 Error：系统故障。 根据国标法规要求，Warning状态中可能还包括Pre-Warning状态。 L1的AEB/LCC等功能仅涉及横向或纵向的单一控制，比如AEB主要负责紧急制动功能，会在FCW Warning后增加Brake的状态。而ACC根据功能定义，会存在Speed Control、Distance Control、Override、Temp Stop等状态。LCC则会存在Lane Keeping等状态。由此可以看出，状态机主要是为功能服务，围绕核心功能而分解为不同状态。 State Flow 逻辑系统建模教材 图来源于笔者 由于L2级别的NOP功能需要同时对车辆进行横向、纵向控制，主状态中的横向控制和纵向控制状态会同时在运行，受限于ODD范围还存在降级的要求，比如Safe Stop等状态，逻辑相对复杂，对兼容性要求较高。 而泊车功能状态机，当然会存在Searching（搜索车位）、Parking（泊车过程）、Suspend（泊车中断）、Completed（泊车完成）等状态。 2.事件定义 事件定义：识别系统中可能发生的事件，并为每个事件定义清晰的触发条件。事件可以是传感器输入、用户操作或其他系统内外的变化。 举例说明，在很多系统中，OFF-Standby的触发事件为“车辆的为IGN ON状态”即车辆已经上电，这个事件可以被认为是车辆状态输入。Stadnby-Active的触发事件可能为“用户点击中控屏幕上的功能开启按键”，这个事件可以被认为是用户操作，等等。 如果系统中存在多个事件，并且它们可以同时发生，那么需要考虑事件的优先级。事件优先级决定了在多个事件同时触发时，哪个事件会被优先处理。例如，紧急制动事件可能具有比前方障碍物检测预警事件具备更高的优先级。 3.转换规则 转换规则：确定状态之间的转换规则，即在特定事件发生时如何从一个状态转换到另一个状态。转换规则应该考虑到系统的逻辑和约束条件。 当我们考虑转换规则时，应当尽量全面而细致，确保状态机的完备性，即确保状态之间的所有可能转换都已经定义和覆盖。缺乏完备性可能导致系统出现未定义的行为或状态异常，从而使状态机跳入死循环无法跳出bug。通过仔细分析系统需求和设计，期望确保所有可能的状态转换都被考虑和定义。 4.动作和行为 动作和行为：为每个状态和状态转换定义相应的动作和行为。这些动作可以是执行特定的功能、发送控制命令、更新状态变量等。 当我们考虑状态时，可以辅以该状态下的工作描述。比如在APA自动泊车系统中，当我们进入Parking状态后，状态机应当负责与车辆控制系统进行握手，握手成功后由Control模块进行控车。（此处仅为举例，握手也可以由其他模块完成） 5.错误处理 **错误处理：考虑系统可能发生的错误和异常情况，并为其设计相应的处理机制。**包括错误状态的定义、错误处理流程以及恢复机制，一般统一由Error状态进行处理和管理。 6.代码生成与测试 **状态机是一个比较有历史的东西，很多厂家为了它做了相关的开发，方便我们使用和测试。 Stateflow是MATLAB/Simulink中的一个工具，用于建模和设计复杂的状态机。它提供了一个图形化界面，可以轻松地创建、编辑和调试状态机模型，并自动生成相应的代码。 Stateflow的主要功能包括以下几个方面： 1. 状态机建模 ：Stateflow提供了丰富的建模元素，如状态、转换、事件、条件、动作等，可以直观地描述系统的状态和状态之间的转换关系。通过拖拽和连接这些建模元素，可以轻松地构建状态机模型，并定义状态之间的转换条件和相应的动作。 2. 事件驱动 ：Stateflow基于事件驱动的模型执行方式。系统的状态转换是通过触发事件来驱动的。可以定义各种类型的事件，如输入信号、定时器、条件判断等。当满足转换条件时，Stateflow会相应地执行转换并触发相应的动作。 3. 动作执行 ：在状态转换过程中，可