浅谈AP autosar 之 runtime 基础

AP Autosar

Architecture

overview

AP autosar在SOC 中的位置,起到的作用。下面图可以看出,AP autosar封装了操作系统的接口,封装了功能安全,信息安全的接口让应用层软件可以脱离操作系统进行独立开发,使用ap autosar定义好的统一接口。完成了应用层和操作系统之间的解耦,提供了统一通讯接口,使得app与app之间实现了解耦。极大的减少了牵一发动全身的影响,增大了各地同步开发的可能性。(图来自ap 官网)


浅谈AP autosar 之 runtime 基础

Execution Management - runtime

浅谈AP autosar 之 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

浅谈AP autosar 之 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

浅谈AP autosar 之 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

浅谈AP autosar 之 runtime 基础

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 

浅谈AP autosar 之 runtime 基础

一句话总结,运用POSIX 接口。

这里提一下通讯方式。哪些被限制了,哪些是可以的。(图来自ap 官网)

两个AA (adaptative application)之间是不被允许直接进行IPC (internal process communication)的。两个AA 之间想通讯 需要 经过 ara::com 模块进行通讯。 AA 只可以用过POSIX51 的 API 与 基础软件Foundation进行通讯。AA如果需要ap 里面services 可以直接与FC 通过 ara::com 进行通讯。附加一张一次研讨会供应商的图。

浅谈AP autosar 之 runtime 基础

但是这一切只是规定,或者叫规范。本身是都可以通讯的。。。(手动狗头)

就比如ap autosar 实现的过程,自身的function clusster 是可以通过IPC, IPC 进行通信的。

这里让我想到MISAR 对C 实用过程的要求,尽量不使用#pragma,文档,comment,都到位的情况下 也是可以的。

规则 3.4(强制): 所有#pragma 指令的使用应该文档化并给出良好解释。

[实现 40]

这项规则为本文档的使用者提供了产生其应用中使用的任何 pragma 的要求。 每个 pragma的含义要写成文档,文档中应当包含完全可理解的对 pragma 行为及其在应用中之含义的充分描述。

应当尽量减少任何 pragma 的使用,尽可能地把它们本地化和封装成专门的函数。  

ps: 如有问题 请多指教 

作者:Z-ONE_00751242454
文章来源:上汽零束SOA开发者论坛 
原文链接:https://bbs.z-onesoft.com/omp/community/front/api/page/mainTz?articleId=7709

上一篇:#pragma comment(lib,“urlmon.lib“)


下一篇:面向数据编程 Data-Oriented Programming [23]