其他分享
首页 > 其他分享> > 612_AUTOSAR_RS_Main_AUTOSAR的方法论

612_AUTOSAR_RS_Main_AUTOSAR的方法论

作者:互联网

         全部学习汇总:https://github.com/GreyZhang/hack_autosar

         我前面过高预估了我自己看文档的速度,看起来这部分文档读起来还是比较费时间的。但是一旦熟悉了,或许速度会快一些。继续吧!今天看看第一份文档中的另一个章节:方法论。

         需要提供整个系统接口的描述方法,这个是软件重用或者合作开发的一个重要前提。其实,我一直觉得POSIX的接口标准是这方面的典范。而在设计大型系统的时候,需要分而治之,这样,软件接口的标准化就十分重要了。

         提供知识产权的保护机制,其实这个或许是现在中国整个科技圈中最被忽视的一点。而对于一般的工程师来说,掌握知识应用本身其实更加重要。这一点,我也暂时跳过不看了,后面如果有更加精确的描述的时候是否会看届时再说。

         提供数据交换格式,用于支持大型公司团队的内外部开发合作。估计这个会是我现在接触到的arxml的文件?

         需要提供一种应用软件模块的描述方法。这部分的设计,主要的考量点也是软件的重用性。

         这个设计理念是很好的,也是应该如此的。这也是现在我所在的团队的一个问题所在。其实,AUTOSAR各种层级的划分就是为了能够让大家能够拆分不同的任务,在不同的层级上进行专注开发。而现在看到的做法是一个人从头做到底,或者是几个人各自把某一个层级切片从头做到底。这样,失去了分工合作设计本身的意义所在。

         需要提供集成应用软件的时候相关方面所有的描述需求格式。这个主要解决的问题是,保证能够获知每一个需要集成的应用软件所需要的的运行时环境。说起来,现在我在工作中看到的现象其实是缺少这样的体现的。

         支持计时的需求,可以支持计时需求的描述以及修改实施。这包括数据流以及控制流相关的需求。这个主要是要满足应用软件的特殊计时需求?

         支持汽车多样性的管理,这个主要是考虑应用软件的兼容性。在一定程度上,这个应该是对应用软件设计的一个要求。

         应该提供典型角色以及工作在共享工作模型中的一个预定义。典型的角色有车辆架构师、领域架构师、ECU集成商、功能设计师。角色也可以与不同的学科相关,如静态体系结构、动态体系结构、通信体系结构等。典型的活动可以是软件/软件分区、软件到ECU的映射、基本软件的配置。综合来说,就是应该定义好有什么人,要做什么样的事儿。

AUTOSAR流程应支持工作共享模型中的角色和权限。分布式开发需要明确的职责。

AUTOSAR应支持表达角色及其创建/访问/修改AUTOSAR描述的权利的通用方法。

这部分的描述,看上去有些类似项目管理的要求,对每一个人能够做的事情进行明确的权限界定。这样的话,可以减少不同人修改他人模块的风险。

标签:AUTOSAR,层级,角色,612,应用软件,软件,Main,描述
来源: https://blog.csdn.net/grey_csdn/article/details/117391748