overview
AP autosar在SOC 中的位置，起到的作用。下面图可以看出，AP autosar封装了操作系统的接口，封装了功能安全，信息安全的接口让应用层软件可以脱离操作系统进行独立开发，使用ap autosar定义好的统一接口。完成了应用层和操作系统之间的解耦，提供了统一通讯接口，使得app与app之间实现了解耦。极大的减少了牵一发动全身的影响，增大了各地同步开发的可能性。（图来自ap 官网）
Execution Management - runtime
execution management 是AP autosar foundation里的一个功能簇。由上图可以看出，execution management 是在系统boot之后启动的然后对程序进程管理.（图来自ap 官网）
Execution management 控制如何启动应用层实例程序，进程的创建与配置
State Management 控制着何时去start 或者 stop 应用层实例程序，比如相应状态改变请求
资源管理，CPU 内存占用，时间管理等 接口函数
在创建执行管理时最重要的四个点
需要执行的executable是什么，换句话就是要管控什么可执行文件
UID 和 GID （Linux 系统中，每个用户的 ID 细分为 2 种，分别是用户 ID（User ID，简称 UID）和组 ID（Group ID，简称 GID），这与文件有拥有者和拥有群组两种属性相对应）
部署在哪个machine上，上文说到应用层之间相互解耦，也就是说 从上层架构层面 可以将不同的app部署到不同的ECU 上，这里要定义一下app想部署在哪个machine上。
执行状态，定义这个可执行程序 在 哪个状态下去执行。比如在machine上定义了startup 和 shutdown两个状态，你可以把这个程序放到startup阶段。这样在linux启动的时候会先去激活execution management，然后执行管理会根据用户定义的状态去执行用户的部署规则。也就是manifest文件中定义的。这点也是ap autosar 和 cp autosar 很大不同的点，本文只简单说一下大概。后面对每个模块进行详细说明。
//在状态在start的时候创建了一个叫alwaysHello_process的进程
ExMConfig::start(ILoaderRegistrar& reg)
{
InstanceIf* alwaysHello_process = reg.getNewInstance();
...;
} State Management - runtime
State Management通过ara::com提供了一组“Trigger”和“Notifier”字段。SM本质上监听“触发器”，并在内部执行特定于实现的状态机处理，如果有“通知”字段，则提供效果。State Management还通过其他fc提供的标准接口与它们进行交互。使用该机制可以达到以下效果:——FunctionGroups可以要求设置一个专门的状态——(部分)网络可以请求deactive /active 这台机器可以要求关机或重启,其他自适应(平台)的应用程序可以影响他们的行为——项目可以执行特定操作。（图来自ap 官网）
其中一些功能是至关重要的。因此，对触发器字段的访问必须由Integrator通过身份和访问管理适当地保护，以免意外地更改状态管理的内部状态(以及由此产生的依赖效果)。
State Management的内部状态通过其提供的“Notifier”字段传播到系统。对这些字段的读访问不那么重要，因此每个Adaptive (Platform)应用程序都可以注册到它们的事件，以便在状态管理的内部状态发生变化时得到通知。因此，当状态管理的状态发生变化时，每个自适应(平台)应用程序都可以(在需要时)执行一个操作。
Log and trace - runtime
log and trace是个比较实用却又尴尬的模块。实用在于可以实时记录，形成log文件，后期查看对比。尴尬在于作汽车软件的都知道，在运行过程中有些东西需要在线标定。目前这个东西时不足以支持在线标定。虽然支持TCP/IP 但是和传统的汽车软件工程师的标定手段相比还是极其的不友好。下面列一下log的一些level, 可以和linux 内核打印level同步对比。（图来自ap 官网）
ap autosar log等级
| Level | Notes |
| ----------- | ------------------------------------------------------------ |
| Fatal | Fatal incorrect behavior; the application is unable to continue |
| Error | Incorrect application behavior and functionality adversely affected. The application results should not be used. |
| Warn | Indicates a failure to achieve fully correct application behavior. The application results are not to be considered trustworth. |
| Information | High-level informational messages aimed at assisting the understanding of program flow |
| Debug | Detailed information intended for the use of programmers/developers |
| Verbose | Highly loquacious; all error messages reported. |
| Off | No messages |
linux 内核 printk 打印等级，数字越低等级越高
#defineKERN_EMERG"<0>"
#defineKERN_ALERT"<1>"
#defineKERN_CRIT"<2>"
#defineKERN_ERR"<3>"
#defineKERN_WARNING"<4>"
#defineKERN_NOTICE"<5>"
#defineKERN_INFO"<6>"
#defineKERN_DEBUG"<7>"
目前log模块对log文件的大小没有特定限制，这是好事但也需要工程师在运用过程中注意内存消耗不要太大，需要代码实现自动清空或者设置大小。
Core
autosar 官方文档 对C++14 使用过程中进行了一些限制，其中有一条就是针对异常机制。（图来自ap 官网）
exception handling --> Dunamic exeption specification
function - try - blocks 这两条都是禁止使用的。为什么提到这个呢，因为我对CORE 的理解（可能存在偏差）是一种返回机制。
Core提供了自适应应用程序的AUTOSAR运行时的初始化和反初始化以及进程终止的功能。AUTOSAR为AUTOSAR API选择了一种无异常的方法，因为它被认为从API返回错误而不是使用异常更有效，并且能够更好地推理程序的控制流。Result类型支持无异常API，同时维护一种自然的编程风格，在这种风格下，API可以以正常方式返回结果，同时支持错误返回值。这点理解的不是很深，它不是一个库，也不是一个进程，是一种返回的状态。
Operating system interface
一句话总结，运用POSIX 接口。
这里提一下通讯方式。哪些被限制了，哪些是可以的。（图来自ap 官网）
两个AA (adaptative application)之间是不被允许直接进行IPC (internal process communication)的。两个AA 之间想通讯 需要 经过 ara::com 模块进行通讯。 AA 只可以用过POSIX51 的 API 与 基础软件Foundation进行通讯。AA如果需要ap 里面services 可以直接与FC 通过 ara::com 进行通讯。附加一张一次研讨会供应商的图。
但是这一切只是规定，或者叫规范。本身是都可以通讯的。。。（手动狗头）
就比如ap autosar 实现的过程，自身的function clusster 是可以通过IPC, IPC 进行通信的。
这里让我想到MISAR 对C 实用过程的要求，尽量不使用#pragma，文档，comment，都到位的情况下 也是可以的。
规则 3.4（强制）： 所有#pragma 指令的使用应该文档化并给出良好解释。
[实现 40]
这项规则为本文档的使用者提供了产生其应用中使用的任何 pragma 的要求。 每个 pragma的含义要写成文档，文档中应当包含完全可理解的对 pragma 行为及其在应用中之含义的充分描述。
应当尽量减少任何 pragma 的使用，尽可能地把它们本地化和封装成专门的函数。
https://bbs.z-onesoft.com/omp/community/front/api/page/mainTz?articleId=7709
https://bbs.z-onesoft.com/omp/community/front/api/page/mainTz?articleId=7709