1 前言
应用模式（Application modes)用于区分不同的场景，以便在系统运行时，组织各自相互独立的OS相关的资源集合，是一种分而治之的思想体现。不同的应用模式是互斥的，即系统当前必须在一种应用模式（且只能在一种应用模式下）运行。
举个例子来说，end-of-line(EOL)的刷写模式和系统正常工作模式，必然是两个相互独立的应用模式，其需求设计也是面向完全不同的场景。
2 应用模式概述
很多ECU都会执行完全独立的应用（applications)，包括工厂测试（factory test)，固件刷写(flash programming)或正常工作操作（normal operation)。显然，可以将应用模式看成满足特定场景的软件模式，以其对应的应用实现来组织代码，使得各场景应用之间的开发解耦。
通常来说，不同应用模式都会使用自己的一套系统资源，包括task，ISRs，alarms及定时器。当然，如果应用模式之间存在功能上的交集，共享这些系统资源也是允许的。反之，要么给每个应用模式配置独立的系统资源（例如task），不同的应用模式运行不同的task；亦或者，需要在任务运行时做条件判断，以运行不同应用模式下的代码分支，这其中有一个运行速度（runtime)和资源开销之间的折衷考虑。
通过应用模式将不同的场景需求及其软件设计分割开来，有利于降低软件的复杂度，OS相关的资源管理与规划也会相对简单。
3 启机性能（start up performance)
在系统运行中，通常存在系统复位的需求。因此，启机性能对于车载软件系统来说尤为重要。所以，用于确定应用模式的逻辑必须简单高效，尽量减少时间开销。如图1所示，系统启动时，用户层代码通过系统服务来确定当前的应用模式，并将之作为参数传递给系统接口StartOS（通常建议通过pin脚状态或相似的条件判断来快速确定应用模式）。
图1 系统启动（system start up）示意图
简单来说，必须在OS内核启动前确定当前的应用模式（显然，此时系统服务还无法使用）；同时，不同的应用模式通过静态配置，对应着不同的系统资源，并由StartOS来调用以完成对应的系统初始化。
4 应用模式相关支持
应用模式在一致类（conformance classes）这一维度并没有做区分，反而一视同仁，做了统一要求。应用模式的定义对于关机功能（shutdown functionality）来说没有影响。
此外，不支持在运行时（runtime）进行应用模式间的切换，即必须通过复位来实现。
