Autosar - 【1 OS模块】

Autosar (Automotive Open System Architecture)是一种汽车电子系统的标准化框架，旨在提高汽车电子系统的可重用性、可扩展性和可靠性。OS模块是Autosar中的一个重要模块，用于管理汽车电子系统中的任务和资源。

1.1 OS模块的基本原理

OS模块是Autosar中的一个重要模块，主要用于管理汽车电子系统中的任务和资源。在OS模块中，每个任务都有一个独立的任务控制块（Task Control Block，TCB），用于记录任务的状态、优先级、堆栈指针等信息。任务之间通过事件、信号量等同步机制进行通信和协调。OS模块还提供了各种资源（如锁、事件、信号量等），用于管理共享资源的访问。

OS模块还负责调度任务，根据任务的优先级和调度策略（如固定优先级调度、时间片轮转调度等），将CPU时间分配给各个任务。在任务切换时，OS模块还需要保存和恢复任务的上下文，包括寄存器值、堆栈指针等。

除了任务管理和调度，OS模块还提供了一些服务，如时间管理、定时器管理、异常处理等。其中，时间管理用于记录系统时间和处理定时任务，定时器管理用于处理周期性任务，异常处理用于处理CPU异常（如非法指令、内存错误等）。

1.2 OS 3层的处理级别

1. 中断级
2. 逻辑级
3. Task级

在Task级别，根据其用户分配优先权Task被调度（没有，全或是混合抢先调度），运行时间方面，是在开始执行时间时被占用，以及在任务完成时被再次释放。

以下是优先级规则定义：

1. 中断优先于Task；
2. 中断的处理级别由一个或多个中断优先级组成；
3. 中断服务的流程有一个静态分配中断的优先级标准；
4. 对于中断服务例程优先级的分配取决于执行和硬件结构；
5. Task优先级是被用户静态分配的；
6. 0是最低优先级，数值越大优先级越高。

1.3 Startup和Shundown 

OS 操作系统的启动是通过调用“StartOS()”函数来实现。在标准的 AUTOSAR 项目中，StartOS 函数由 EcuM_Init 调用。OS系统可以设定不同的应用模式，用户可以在不同的应用模式下运行不同的应用程序，从而在不同的条件下实现不同需求，需要给StartOS指定应用模式参数。 OS系统支持多种应用模式共存，并提供配置选项供用户在系统配置阶段建立和选择所需的应用模式。一旦操作系统启动，应用模式就不能再更换，也就是说在系统运行过程中动态切换应用模式是不允许的。

StartOS()会对OS内部各组件进行初始化，激活自启动任务、报警或调度表。StartOS()的最后，会启动系统定时器，并触发第一次任务调度。如果用户使能了相关 Hook，StartOS 会在所有初始化完成之后，启动系统定时器、触发第一次任务调度之前，调用用户的 Hook，调用顺序为：

1. 调用 OsStartupHook
2. 调用各个 OS-Application 的 OsAppStartupHook

OS 操作系统的关闭是通过调用“ShutdownOS()”函数实现。“ShutdownOS()”函数会禁能所有中断,停止系统定时器运行，最终进入死循环。如果用户使能了相关 Hook，ShutdownOS 会在进入结尾处，进入死循环之前，调用用户的 Hook，调用顺序为：（1）调用各个 OS-Application 的 OsAppShutdownHook。（2）调用 OsShutdownHook。

1.4 Task

任务是Autosar OS的最小调度单元，它是一个可以独立执行的代码单元，可以访问共享资源、发送和接收消息等。任务可以是预定义的或动态创建的，可以按照优先级进行调度。Autosar OS支持多种不同的任务类型，包括基本任务、扩展任务、周期任务和自启动任务等。

1.4.1 Task的符合类

AUTOSAR OS根据不同的软硬件需求，根据每个优先级可能具备的任务个数以及需要的是基本任务还是扩展任务等来定义了四种符合类分别为BCC1，BCC2，ECC1以及ECC2。

BCC1与ECC1不支持多次任务激活请求且每个优先级只能有一个任务；BCC2与ECC2既支持多次任务激活请求，同时也支持每个优先级可以有多个任务。各种符合类之间的兼容关系如下图所示：

1. BCC1（只对基本的Tasks，所有的Task有不同的优先级，被限制只能有一个请求激活每个Task和每个优先级只能有一个Task）
2. BCC2（象BCC1，但每个优先级可以有多个Task和允许多个请求激活Task）
3. ECC1（象BCC1，增加扩展Tasks）
4. ECC2（象ECC1，但每个优先级可以有多个Task和允许多个请求激活Basic Task）

当 OS 符合类为 BCC1 或 ECC1 时，不支持任务的多次激活，不支持为不同的任务分配相同的优先级。因此每个优先级上有且只有一个任务。当 OS 符合类为 BCC2 或 ECC2 时，支持任务的多次激活，支持为不同的任务分配相同的优先级。此时 OS 会为每个优先级创建任务队列，队列深度与该优先级上任务的个数和最大激活次数相关。

如果操作系统的符合类被配置成 BCC2 或者 ECC2，那么系统将支持任务的多次激活。系统中只有Basic Task能够进行多次激活，Extended Task只能激活一次。所以在配置Basic Task的时候都会配置一个参数叫做Task Activation，意思就是多次激活的次数限制，比方说一个Basic Task1被设置成5ms激活一次，但是此时OS被一个高优先级的任务block住没有时间来运行这个Task，那么这个任务就会出现被激活多次但是没有执行一次的情况，而这里的Task Activation则是限制这个被激活的次数，一旦超出这个次数，则OS会报错。

1.4.2 Task状态模式

AUTOSAR OS中存在两种任务：

1. 基本任务Basic Task：包含状态Ready，Running，Suspend
2. 扩展任务Extended Task：包含状态Ready，Running，Suspend和Waiting

基本任务则存在以下三种状态：

1. 运行状态(Running)：处于运行状态的任务可能被高优先级任务或者中断抢占从而进入就绪状态，且同一Core中任何时刻只会存在一个任务处于运行状态，任务运行结束后则将自己挂起进入阻塞状态；
2. 就绪状态(Ready):  处于就绪状态的任务由调度器决定是否启动进入运行状态，且该状态时任务切换至运行状态的前提；
3. 阻塞状态(Suspend): 处于阻塞状态的任务是被动的，可以由API函数或Alarm激活进入就绪状态；
4. 等待状态(Waiting)：扩展任务与之相比，多了此状态。当任务的运行需要等待某一或某些事件被置位时，任务进入就绪状态。

基本任务与扩展任务的状态机切换如下图所示：

基本任务没有等待状态，所以只能在任务启动与终结时进行同步，基本任务的优点就是占用较小的任务与执行时间。

扩展任务则包含多个同步点，没有同步请求的麻烦，当进一步的条件无法满足时，任务则会切换至等待状态，其缺点也很明显，会占用较多的内存和执行时间。

 1.4.3 Task调度策略

OS根据任务是否会抢占有三个不同的配置，分别是：

1. 在完全抢占调度策略下，所有 OS 的任务均为可抢占的。高优先级任务会抢占低优先级任务
2. 在完全非抢占调度策略下，所有 OS 的任务均为不可抢占的。任何任务在运行时，都不会被其他任务抢占
3. 在混合调度策略下，用户可配置任务是否可抢占。

OS 中所有的任务都是静态配置的，在系统启动时就已经存在了。

可以使用系统服务函数或“ChainTask()”来激活一个任务。系统服务函数“ActivateTask()”将处于挂起状态的任务转换为就绪状态，如果在某任务运行过程中调用了 ActivateTask()，且当前任务为可抢占任务，则ActivateTask()会基于优先级进行任务调度。如果当前任务为不可抢占任务，则ActivateTask()不会触发调度。系统服务函数“ChainTask()”会终止当前正在运行的任务，同时激活一个新任务，然后会触发一次系统调度。在真实应用，其实这两个函数用的不多，瞎勾吧用的话会对系统任务的运行状态造成不可控的时序因素。一般就是使用ActivateTask()来激活Extended Task，Extended Task只需要激活一次，Extended Task启动后，然后就是处于 WAIT 状态等待event，event发生执行后再次等待下一次event；而Basic Task则需要用Alarm来周期性激活，因为Basic Task每次运行完都需要调用TerminateTask()进入阻塞态。其实简单来说，Extended Task像是一个死循环，而Basic Task更像是一个Callback。

1. 全抢占式调度

对于完全抢占式任务调度策略而言，当前运行的任务可在任何时刻被高优先级任务打断而被迫释放处理器控制权，具备最高优先级的任务从就绪状态转入运行状态，而当前任务被抢占从而进入就绪状态，同时保留现场环境，待下次运行时恢复。

如下图所示为完全抢占式任务调度策略，TaskA为扩展任务，TaskB与TaskC为基本任务，优先级TaskA > TaskB > TaskC。

1. 场景1：

当前TaskC处于运行状态，当激活TaskB进入到就绪状态时，由于TaskB优先级高于TaskC，所以TaskC被迫释放处理器控制权，调度器开始调度TaskB从就绪状态变为运行状态，直到TaskB运行完成之后，在调度TaskC继续运行。

1. 场景2：

当前TaskC处于运行状态，激活TaskA与TaskB分别进入就绪状态，由于TaskA优先级高于TaskB，所以TaskA抢占内核运行, 但是由于Resource1仍被TaskC占用，而TaskA无法访问到共享资源Resource1，则被迫进入到等待状态，TaskB开始运行。TaskB运行结束后挂起之后则重新运行TaskC，TaskC运行结束后释放Resource1，进入TaskA得以由等待状态转入运行状态。

此时你会发现高优先级的任务TaskA由于共享资源被占用的原因导致不能先于TaskB运行的现象，该现象也被称为优先级反转现象。

为了解决该问题，在此需要提到AUTOSAR OS的优先级天花板模式：即将访问共享资源的任务优先级在占用资源的过程中提升至共享资源任务的最高优先级之上，从而避免优先级反转现象的发生。

即若TaskC运行过程中占用共享资源Resource1，此时即使存在需占用共享资源的高优先级任务TaskA被激活，也必须保证TaskC运行结束之后才能执行TaskA，也就意味着在重要代码执行之前，应采用资源保护机制，以免被高优先级的任务打断。

1. 非抢占式调度

用非抢占式调度策略，那么当前运行状态的任务在任何时刻都不会其他高优先级任务所抢占，任务的切换只会发生在任务完成时。

非抢占式调度策略的问题在于任务执行时间不确定，系统调度实时性较差。如下图所示为非抢占式调度策略，可见即使高优先级任务 TaskB被激活切换至就绪状态，也必须等到TaskC执行结束之后才能够被调度。

1.4.4 Task调度时序图

在软件架构设计时，为了保证CPU的负载率以及任务的前置条件，需要将每个SWC的Runnable进行定义，根据SWC的属性进行设计，如下图所示。

在原则上，需要定义一些主要规则：

1. SWC对时间要求不高的，尽量将Runnable的时间放长点。
2. 相同Task的Runnable，可以设计多个Task，通过Offset的设置，避开同一周期的Task同时运行。

1.4.5 Task调度构成图

在软件架构设计时，为了让软件架构更加清晰，可以分成三类：

1. ECU在怠速和空转时的任务处理；
2. ECU在上电或唤醒，下电或睡眠时的任务处理，以及总线收发通讯任务和消息处理任务；
3. ECU在Normal模式下运行时的任务处理（这里主要处理和执行功能所需的任务）；

 1.5 Counter

在AUTOSAR OS模块中，Counter是一种特殊的服务，用于提供时间测量和管理功能。它可以用来计算时间间隔、定期执行任务、延迟任务的执行等。

Counter可以用来测量时间间隔，从而实现时间管理功能。在AUTOSAR OS中，Counter的时间单位是tick，也就是时钟节拍。时钟节拍是指系统中固定时间间隔的单位，通常以微秒、毫秒或秒为单位。通过计算tick数，可以得到具体的时间间隔。

Counter可以用于任务调度，以实现实时控制系统的实时性和稳定性。通过设置Counter的周期和最大值，可以实现定期执行任务的功能。例如，在控制系统中，可能需要以固定的时间间隔执行任务以确保系统的稳定性。在这种情况下，可以使用Counter机制来定期执行任务，从而实现系统的实时性和稳定性。

Counter概念的引入是为了实现对硬件计数器以及软件计数器的管理，为Alarm与Schedule table提供支持。

即多个Alarm可以共用一个Counter，一个Schedule Table只能由一个Counter来驱动 。 Counter按照AUTOSAR定义可分为以下两种：

1. SystemCounter：该Counter的增加由硬件外设驱动，如Gpt或者timer等；
2. UserDefinedCounter：Counter的增加通过调用API函数IncrementCounter来实现，且每次只能增加1；

基本原则： 优先使用SystemCounter，因为可以根据Task的激活状况来减少无意义的时钟中断；

如下图所示，则较为清晰的表现了Counter，Schedule Table以及Alarm三者之间的关系。

SystemCounter默认必须存在，该计数器只能通过 SystemTick 进行触发，用户不可修改。Tick 是指 SystemCounter 的计数基值。硬件定时器多久产生一个 Tick 是由 TickTime 确定，TickTime 的单位为μs，默认值为 1000μs。用户可以在配置工具中根据需求对 TickTime 的大小进行配置。为实现 SystemCounter，OS 会占用一个硬件定时器来周期性地产生 System Tick。OS会自动创建该硬件定时器的中断，用户可以更改定时器中断的优先级。

除 SystemCounter 外， OS 支持用户自定义的 counter。用户自定义的 counter 没有固定触发源，用户需要调用 IncrementCounter 触发自定义Counter 增加。例如在周期任务或其他的定时中断中调用，也可使用 Alarm 触发自定义 Counter，Alarm 的动作中可选择IncrementCounter。

 1.6 Alarm

AUTOSAR OS模块中的Alarm（定时器）是一种重要的机制，用于在预定时间点触发任务的执行。Alarm通常用于在特定时间间隔内定期执行任务，以及在将来的某个时间点触发任务的执行。

Alarm的作用在于使任务能够在预定的时间点执行，以实现复杂的任务调度和协调。Alarm通常由两个主要组件组成：Counter和Alarm。Counter是一个计时器，用于跟踪时间的流逝，并提供时间基准。Alarm是一个相对于Counter的定时器，它在预定的时间点触发任务的执行。

通过Alarm，任务可以实现复杂的时间同步和协调。例如，在实时控制应用程序中，任务可能需要在固定的时间间隔内执行，以确保控制系统的稳定性和可靠性。在这种情况下，任务可以使用Alarm机制来定期执行，从而确保系统的实时性和稳定性。

Alarm相当于是一个软件定期器，可以使用Alarm进行定时，定时时间到后，执行相应的动作。

Alarm支持的动作有：

1. 激活一个Task
2. 设置一个Event
3. 运行一个Alarm Callback函数（Alarm Callback只在 SC1 中提供）
4. 累加一个UserDefinedCounter。

有两种方法可以启动 Alarm，自启动的 Alarm在OS启动后就自动开启了。对于非自启动的 Alarm，用户需要调用 SetAbsAlarm()或SetRelAlarm()启动报警，设置报警的启动时间和周期。 SetAbsAlarm()和SetRelAlarm()的区别在于是相对延时还是绝对延时。

当到达Alarm所对应的计数器设定值时，则可以激活一个任务，设定一个event，调用callback或者增加计数器等功能，但只能是一对一。

不能像Schedule Table那样，能够在Expiry point同时设定多个Task或者多个Event，这也是为什么引入Schedule Table的原因。

一个软件Counter + 多个Alarm队列就可以实现静态定义的任务激活机制。但随着Schedule Table的引入，因此一般建议能用Schedule Table就不要用Alarm。

1.7 Resource

OS 提供了Resource管理功能，用于解决任务或中断同时访问共享Resource时的协调问题。共享Resource可以是应用程序段、内存空间或者硬件外设等。OS 的Resource管理机制可以防止Resource死锁，任务优先级反转等问题。

GetResource()和ReleaseResource()用来进行锁住和释放Resource。这个时间就会出现优先级反转的情况，这样做是为了避免两个不同优先级任务访问相同Resource而出现互锁的情况，具体做法为：任务或中断调用 GetResource 获取Resource时，OS 会将任务或中断的优先级提升至最高优先级。之后，访问该Resource的其他任务或中断将无法抢占当前任务，直到该Resource被释放，Resource被释放时，OS 将会恢复该任务或中断的原先优先级。

因为任务的优先级为软件优先级，而中断的优先级为硬件优先级，这两种优先级不在一个层次，所以如果当一个Resource是任务和中断共享的，当该Resource被任务获取后，OS 将会锁定调度（所有任务和二类中断都不能抢占当前任务，包括与当前Resource无关的任务和二类中断），这样做是为了防止使用该Resource的中断被锁定的时间过长。

1.8 Event

在Autosar OS模块中，事件(Event)是一种重要的机制，用于实现任务间的同步和通信。事件是一种标志，用于表示某个特定的状态或者条件发生了变化，任务可以通过等待事件的发生来实现阻塞等待和异步通信。

在 Autosar OS 中，event 是一个特殊的系统对象，它允许软件组件通过信号和槽（signal and slot）机制进行异步通信。一个 event 可以有多个槽，每个槽都与一个软件组件相关联。当 event 被触发时，与之相关联的所有槽都会被调用。因此，event 可以看作是一种异步通知机制，它允许软件组件在不知道其他组件的存在或状态的情况下进行通信。

事件通常是由任务发送的信号，其他任务可以通过等待该事件来等待信号。当事件被设置时，等待该事件的任务将被唤醒并开始执行。任务可以使用事件来同步对共享资源的访问，确保它们在不同任务之间进行合理的协调和同步

Autosar OS模块中的事件可以分为两种类型：自动复位事件和手动复位事件。自动复位事件是指当任务等待的事件发生时，事件标志会自动复位，任务需要重新等待事件的发生；而手动复位事件是指当任务等待的事件发生时，事件标志不会自动复位，需要由任务手动复位。

Autosar OS提供了一系列标准的API用于管理和操作事件，例如SetEvent、WaitEvent、ClearEvent等。任务可以通过SetEvent API来设置事件标志，通过WaitEvent API来等待事件的发生，而ClearEvent API则用于手动复位事件标志。

事件机制可以实现任务间的同步和通信，例如一个任务可以等待另一个任务发出的事件信号来启动某个操作，或者多个任务可以通过事件机制来共享某个资源的使用权。同时，Autosar OS模块中的事件机制还支持多种事件类型，例如二进制事件、计数事件等，可以满足不同应用场景的需求。

Event用于实现系统内不同的实体之间的同步，包括任务与任务进行同步或是任务与中断服务函数进行同步。只有扩展任务可以调用 WaitEvent 等待Event，调用 WaitEvent 后，任务不再运行，进入WAIT 状态。

任务和二类中断中可以调用 SetEvent 设置事件，另外Alarm，Schedule Table 也可以配置设置事件的动作。设置事件后，等待该Event的任务将恢复至 READY 状态。然后 OS 会基于当前系统的抢占策略，任务优先级的情况，确定何时恢复任务的运行。每个扩展任务支持最多 32 个事件。WaitEvent 和 SetEvent 均可以等待或设置多个事件。

1.9 Interrupt

Autosar将中断(Interrupt Service Routine: ISR)分为两类：

ISR Category 1: 该类型ISR不使用OS Service。当ISR触发时，MCU直接调用中断向量表中的用户指定的中断服务子函数；ISR执行完后，回到之前被中断打断的那条指令处继续执行。该类型中断不影响task调度。实时性较高。

ISR Catogory 2: 该类型中断由OS管理。当ISR触发时，MCU调用中断向量表中的OS Service，在该Service中再调用用户的中断服务子函数。ISR执行完后，可能会触发task调度。

Note：

1. ISR Category 1中断优先级需高于ISR Category 2
2. ISR(包括Category1 和 2)的优先级高于task。

中断对整个MCU的重要程度不言而喻，连OS的基本架构都是基于三个中断来实现的。光拿对于中断的应用来说非常简单，其实就是配置中断处理函数的名称，在中断触发后，OS 经过预处理之后，会调用该处理函数。中断处理函数由用户实现。但是要是将中断合理的使用，使用的稳定还是需要对中断的机制要有一定的了解，不然就会出现一大堆勾吧问题。

AUTOSAR OS 将中断分为一类中断和二类中断。其中一类中断就比较简单粗暴，它跟传统意义上的中断执行是一样的，中断发生后直接打断当前运行任务（支持中断嵌套的话，也可以打断低优先级中断），然后运行中断服务函数，运行完之后直接回到打断处的地方继续运行；而二类中断则在结束后会触发任务调度，让任务调度来决定去哪里执行。

中断示意图：

所以根据上面的区别，一类中断和二类中断触发时，两者所干的事情有所区别。

1. 对于一类中断来说，运行流程为：

1. 中断发生，打断当前运行状态
2. 保存恢复现场
3. 切换 OS Context
4. 调用用户的处理函数
5. 退出中断，回到原先状态继续执行。

一类中断对于整个OS来说，纯纯粹粹就是一个强硬中断。正因为一类中断的简单粗暴，所以在使用它的时候，需要考虑的因素就比较多：

1. 在一类中断中，有很多涉及到OS操作的函数以及特征都不能被调用，比如一类中断不支持Resource
2. 一类中断运行时，其内存访问权限和 OS 内核是一致的（最高权限）
3. 一类中断没有独立的栈，其使用的是被其打断的任务或中断的栈
4. 如果任务或二类中断使能了时间保护，一类中断不会暂停时间保护的计时。

1. 对于二类中断来说，运行流程为：

1. 中断发生，打断当前运行状态
2. 保存和恢复程序上下文
3. 切换 OS Context
4. 记录中断嵌套的信息
5. 处理被打断任务或中断，以及当前中断的时间保护
6. 切换内存访问权限
7. 切换堆栈
8. 调用用户服务函数
9. 退出中断，并触发任务调度，如果当前有中断嵌套，则恢复程序上下文，恢复至被打断的中断。如果无中断嵌套，且没有更高优先级的任务被激活，则恢复程序上下文，恢复至被打断的任务。如果无中断嵌套，但有更高优先级的任务被激活，则切换至新的任务。

二类中断对于整个OS来说，则就相当于一个特殊Task了，它的开关是受OS控制的，但是也只就局限于开和关，二类中断的触发一般通过硬件来自动触发。一旦OS调度被挂起，那么二类中断就会被屏蔽，不会被触发。

 1.10 Schedule Table

如上Alarm所述，当计数器的计数值依次达到各个Alarm设定的计数值时，各个Alarm被触发，但很难保证各个Alarm有特定的时间间隔。

且每个Alarm只能激活一个Task或者Event，所以需要多个Alarm来协作实现在同一时刻触发多个Task或者Event，因此Schedule Table应运而生！

调度表可以帮助用户更方便的实现一系列具有时序要求的动作。首先说一下EP（Expiry Point），它相当于一个时间点执行对象，当时间到了，Schedule Table就会去执行这个EP，EP可触发多个Task或者触发多个Event，而一个Schedule Table 可配置多个 EP（Expiry Point）。

Schedule Table 可以配置为单次触发运行，或者周期运行，OS可支持同时运行多个调度表。与报警器类似，一个调度表只能由一个Counter驱动，同时调度表存在以下两种调度方式：

1. 单次执行(Single-Shot)：调度表启动之后 只运行一次，到达调度表终点则终止，即每个终结点只运行一次；
2. 循环执行(Repeating)：调度表启动后可反复执行，到达调度表终点后重头开始执行，则每个终结点会被周期性的执行，一般情况下激活任务采用此模式。

Schedule Table的EP执行规则由两个参数决定，分别是整个Schedule Table的Final Delay参数，还有每一个EP的Initial Offet参数，所以当一个调度表被启动后，它的运行流程如下：

首先在Tick 0处Schedule Table被启动，然后根据每一个EP的Initial Offet来决定EP的执行时刻，当最后一个EP执行后，最后等待Final Delay个Tick，整个Schedule Table运行结束如果Schedule Table配置成重复启动，那么此次运行后立即启动下一次Schedule Table的运行。

 1.11 OS Context

OS Context就是当前OS所处的状态，这里的状态其实就是当前程序运行到哪里了，比如说Task内， 一类中断内，二类中断内，还是各种Hook内。不同的状态下，OS所能做的事情也是不一样的，所能做的事也可以简单的理解成能不能调用某些常用OS函数。具体如下图所示：

1.12 普通监测功能

在一般的AUTOSAR OS中，一般需要提供以下几种监测手段：

堆栈检测将进行栈初始化，并且当发生栈溢出的错误现象时，可以及时告知用户并最终执行关闭 OS。当退出二类中断、退出任务时，系统会进行堆栈溢出检测，即检查当前中断或任务是否将预先配置的栈全部使用耗尽。

系统提供 CPU 负载计算功能，调用相关函数，获取最近一次该周期内的系统负载率。

当 OS 内部检测到故障后，OS 会将错误信息记录，比如传参错误，状态错误，总之就是导致函数未正常运行下去的各种错误。还可以定义用户Hook，当检测到错误时，可执行Hook函数。