头条号可以做网站链接吗,交互式网站有哪些功能,哪个网站专业做商铺,海南网纹瓜车载软件架构 —— Adaptive AUTOSAR软件架构中操作系统
我是穿拖鞋的汉子#xff0c;魔都中坚持长期主义的汽车电子工程师#xff08;Wechat#xff1a;gongkenan2013#xff09;。
老规矩#xff0c;分享一段喜欢的文字#xff0c;避免自己成为高知识低文化的工程师魔都中坚持长期主义的汽车电子工程师Wechatgongkenan2013。
老规矩分享一段喜欢的文字避免自己成为高知识低文化的工程师 本就是小人物输了就是输了不要在意别人怎么看自己。江湖一碗茶喝完再挣扎出门靠自己四海皆为家。人生的面吃一碗少一碗人生的面见一面少一面。人生就是一次次减法来日并不方长。自己的状态就是自己最好的风水自己的人品就是自己最好的运气。简单点善良点努力点努力使每一天都开心不为别人只为自己。 本文大体如下
1、操作系统概述
2、执行管理
3、状态管理
一、操作系统概述
操作系统(OS)负责自适应平台上所有应用程序的运行时调度、资源管理(包括监控内存和时间限制)以及Process间通信。OS与执行管理(Execution Management)协同工作后者负责平台初始化并使用OS 执行应用程序的启动和关闭。
自适应平台并没有为高性能处理器指定新的操作系统。相反它定义了一个执行上下文和操作系统接口(OSI)供自适应应用程序使用。
OSI规范包含的应用接口是ARA(自适应应用的标准应用接口)的一部分。OS本身也可能提供其他接口如创建 Process这是执行管理启动应用程序所必需的。但是ARA 并不提供此类功能的接口而且其定义取决于平台的实现。
POSIX
市场上有几种操作系统(如 Linux)提供与POSIX兼容的接口。但是与平台服务和基础相比应用程序必须使用更受限制的 API与操作系统连接。
一般假设是用户应用程序应使用PSE51作为OS接口而平台应用程序可使用完整的POSIX。如果应用层需要更多的功能将尽可能从 POSIX 标准获取而不是重新指定自适应平台基础和自适应平台服务功能的实现可能会使用更多的 POSIX 调用。具体调用的使用将由实施者自行决定不会标准化。
调度
操作系统提供多线程和多Process支持。标准调度策略是POSIX 标准定义的SCHED FIFO 和 SCHED RR。允许使用其他调度策略如SCHED DEADLINE 或任何其他操作系统特定策略但这些策略可能无法在不同的 AP 实现中移植。
内存管理
支持多 Process 的原因之一是实现不同功能集群和 AA 之间的无干扰。OS 对多Process 的支持迫使每个 Process 都处于独立的地址空间与其他 Process 分离并受到保护。同一可执行文件的两个实例在不同的地址空间运行因此它们可能共享相同的入口点地址、代码以及启动时的数据值但数据将位于内存的不同物理页中。
设备管理
设备管理在很大程度上与操作系统有关。自适应平台基金会有意倾向于创建服务来公开主要的系统功能。
虽然目前还没有计划对设备驱动程序本身的具体 APIS 进行标准化但可以通过自适应平台服务对这些驱动程序实现的更高级功能进行标准化。
联网
多台 Machine 之间以及与其他传感器之间的主要互连机制预计将基于以太网。因此TCP/IP-and UDP/IP-based 协议的使用已得到明确说明。因此预计操作系统将提供这样一个网络堆栈。
应用程序将通过使用通信管理从网络支持中获益。作为自适应平台基础的一部分VLAN、IPSEC 等附加功能可实现系统内和系统间的安全通信。
二、执行管理
2.1 概述
执行管理负责系统执行管理的各个方面包括自适应平台的初始化和Process 的启动/关闭。执行管理与操作系统协同工作配置 Process 的运行时调度。
2.2 系统启动
Machine 启动时OS 将被初始化然后执行管理将作为平台的初始 Process 启动。随后执行管理将启动自适应平台基础的其他平台级 Process(代表功能集群)。自适应平台基础启动并运行后执行管理将继续启动自适应应用程序的Process。平台级Process 和应用程序级 Process 的启动顺序由执行管理根据 Machine 清单和执行清单中指定的依赖关系来决定。 自适应应用程序可由多个可执行元素组成这些元素通常与文件系统中的可执行文件相对应。每个可执行文件可以有多个 Process 配置因此启动配置也取决于可执行文件处于活动状态的功能组状态。
执行管理可选择支持验证启动即从信任锚点启动自适应平台同时保持信任链。在验证启动过程中执行管理会验证应用程序的真实性和完整性如果检测到违规行为执行管理会(有选择地)阻止其执行。通过这些机制可以建立一个可信平台。
2.3 执行管理职责
执行管理负责自适应平台执行管理和应用程序执行管理的所有方面包括
1、平台生命周期管理执行管理是自适应平台启动阶段的一部分负责自适应平台和已部署应用程序的初始化。
2、应用程序生命周期管理执行管理负责已部署应用程序的有序启动和关闭。执行管理根据 Machine 清单和执行清单中的信息确定部署的应用程序集并根据已声明的执行依赖关系得出启动/关闭顺序。根据 Machine 状态和功能组状态的不同己部署应用程序的 Process 会在自适应平台启动时或稍后启动但并不是所有应用程序都会立即开始工作因为许多应用程序会向其他应用程序提供服务因此需要等待和监听传入的服务请求。
执行管理部不负责应用程序的运行时调度因为这是操作系统的职责。但是执行管理负责 OS 的配置使 OS 能够根据执行管理从 Machine 清单和执行清单中提取的信息执行必要的运行时调度。
2.4 确定性执行
确定性执行提供了一种机制使使用给定输入数据集进行的计算总能产生一致的输出而不受干扰影响。执行管理区分时间确定性和数据确定性。前者是指输出总是在截止日期前产生而后者是指从相同的输入数据集和内部状态产生相同的输出。
执行管理提供的支持侧重于数据确定性因为时间确定性是通过提供充足的资源来处理的。在数据确定性方面执行管理提供了 DeterministicClient APIs以支持对 Process内部循环、确定性工作池、激活时间戳和随机数的控制。DeterministicClient 与通信管理交互使数据处理与周期激活同步。
2.5 资源限制
自适应平台允许在同一台 Machine 上执行多个自适应应用程序因此确保不受干扰是一个系统属性。因此应限制行为不正确的自适应应用程序影响其他应用程序的能力例如应防止应用程序 Process 消耗超过规定的 CPU时间因为这可能会影响其他应用程序的正常运行。
执行管理支持通过配置一个或多个 ResourceGroups 来避免干扰应用程序的 Process 被分配给这些 ResourceGroups。然后可为每个 ResourceGroup 分配 CPU 时间或内存限制以限制应用程序的可用资源
2.6 可信平台
为保证系统功能的正确性必须确保在平台上执行的代码来源合法。集成商可通过保持这一属性来构建可信平台。
实现可信平台的系统的一个关键属性是可信锚点(也称为可信根)。信任锚通常以公开密钥的形式实现它存储在一个安全的环境中如不可修改的持久内存或 HSM 中。
系统设计者有责任至少确保系统从信任锚点开始并在执行管理启动前保持信任。根据系统设计者选择的建立信任链的机制整个系统的完整性和真实性可能已在系统启动时进行了检查。但是如果系统设计者只确保已执行软件的完整性和真实性已得到检查那么执行管理就会在接管系统控制权时接手继续执行信任链的责任。在这种情况下系统集成商有责任确保正确配置执行管理。
从信任锚向 OS 和自适应平台传递信任(即建立信任链)的一个示例如下:根据定义,信任锚是一个真实的实体它在引导加载器启动前对引导加载器进行验证。在启动过程的每个后续步骤中应首先对即将启动的可执行文件进行验证。真实性检查应由已通过验证的实体完成即真实性检查可由之前启动的可执行文件或 HSM 等外部实体完成。
OS 经过身份验证启动后应将执行管理作为第一个 Process 启动。在启动执行管理之前OS 应确保执行管理的真实性已由通过验证的可信实体验证。
注如果认证不是由信任锚点本身的功能来检查(根据定义信任锚点本身就是真实的)那么用于验证可执行文件真实性的软件在使用前就必须经过认证。例如如果Crypto API用于验证可执行文件的真实性那么 Crypto API本身在使用之前就必须经过某个可信实体的验证。
三、状态管理
状态管理是一个独特的功能集群主要针对 ECU 开发项目一般由系统集成商负责最终实施。它负责 AUTOSAR 自适应平台运行状态的所有方面包括处理传入事件、确定这些事件/请求的优先级以设置相应的内部状态。根据项目需要状态管理可由一个或多个状态机组成。
如下所述状态管理通过由字段组成的项目特定 ara::com 服务接口与自适应应用程序进行交互。状态管理与其他功能集群之间的交互应通过各功能集群定义的标准化接口进行。 状态管理可要求以下效果:
- 1、可要求将 FunctionGroups 设置为专用状态
- 2、可请求删除/激活(部分)网络
- 3、可请求关闭或重启 Machine
- 4、可影响其他自适应(平台)应用程序的行为
- 5、可执行特定于项目的操作
- 6、在收到平台健康管理或执行管理通知时从(监督)错误中恢复
- 7、应诊断的要求根据诊断地址执行特定项目重置
- 8、根据更新和配置管理的要求准备并验证软件集群的安装、更新或删除
- 9、影响运行 Process 的行为以实现 Machine 内部(部分)的同步行为(如电源模式。
为实现同步行为状态管理提供了已定义的消息和回复消息在通讯管理的通讯组范围内可从这些消息和回复消息中生成 ara::com 方法和字段。
状态管理通过 ara::com 提供一组触发器和通知器字段。SM 本质上是监听触发器并在内部执行特定状态机处理如果otifier字段有效果则将效果提供给Notifier字段。
由于状态管理功能至关重要因此必须确保从其他功能组或应用程序的访问安全如通过 IAM(身份和访问管理)。状态管理由平台健康管理进行监控。
状态管理引入了轻量级StateMachine 方法以帮助自适应平台用户创建状态管理功能。StateMachines 的设计旨在以最少的配置工作覆盖标准用例。请注意StateMachines 是 AUTOSAR 的补充部分因此可以选择使用。预计复杂的用例仍需要用户提供源代码
StateMachine 不执行特定项目的逻辑。相反它为特定项目的自适应应用程序(即SMControlApplication)提供输入接口。该应用程序包含项目专用逻辑并决定下一光应请求 StateMachine 的哪种状态。请注意对执行管理和/或平台健康管理报告的错误的反应是直接在 StateMachine 内部配置的。 为了概述 StateMachine 方法下图显示了不同的 StateMachine 实例、相应 StateMachine 的接口、TransitionTable 和 ErrorRecoveryTable 的交互方式。 搁笔分享完毕
愿你我相信时间的力量
做一个长期主义者
