汽车电子产业链技术研发制造人员注册以上线上课可获取以下重磅福利: 1、2021年全年智能座舱测评体系双月刊6期300页; 2、全套智能驾驶功能软件平台设计规范一套5份100页; 3、汽车电子研报10份600页; 4、汽车电子线上课程一节; 5、进入高质量汽车电子社群,与讲师0距离互动; EEA发展趋势 传统的汽车电子电气架构及相应的解决方案很难解决现在遇到的一些挑战,需要新的方法论来打破僵局,于是车载以太网、车载SOA作为解决方案提出来了。 SOA 概述 Broker可以是集中式的也可以是分布式的,如果是集中式的可以在某些设备上统一管理服务的发现;如果是分布式的类似以太网、SOME/IP协议等可以在汽车的每个ECU上充当角色来实现服务发布和订阅。 为什么要用SOA? 降低复杂性 SOA与以太网的关系 如果要实现SOA的架构,在项目启动时,首先要确保能落地的SOA电子电气架构梳理出整车以太网的拓扑需求,从方方面面出发和产品、功能架构、平台软件等相关的去共同确认电子电气架构为确保以太网的拓扑和相关以太网芯片的选型,也需要根据一些实际的条件选择合适的SOA服务协议。 下图是当前常用的四种服务协议。 ETH系统设计与SOA开发流程 在车载架构中以太网和SOA是一个最强的搭档,如果要实现SOA的落地,理论上以太网是要先行的。 就部分主机厂来说,它们下一代架构先实现的功能是DoIP,要让一部分的域控制器先实现基于以太网的通信,实现TCP的IP协议栈,让整车架构中的ECU先去有通信的能力以及整车安全方面的一些部署并且能够让一些工程师能实现整车上通过OBD接口去实现车辆的ECU登录,车辆报文的录制等等技术的实现。 ✦✦ ETH系统设计流程 在以太网项目落地或SOA设计开发前,大量的OEM厂家最先是从预研先开始的,首先以太网的相关设计流程要求相关的工程师建立一定的知识储备,先去实现一些规范体系的建设。 如上图所示,规范体系建设主要包含三部分内容:
协议需求规范 这部分包含一些比如以太网通信需求规范等,是对协议的功能原理去进行一些解析,对相关的属性和参数去进行约束。 全局规划类规范 这个规范是在整车的全局上,比如VLAN & IP划分的原则,IP定义的规则,IP地址定义的一些前缀的定义要求,不同的VLAN & IP划分的原则以及每个ECU后缀的一些划分规律等全局的一个规范。 项目交付类规范 比如ECU以太网参数配置规范,涉及到ECU在以太网从底层到上层相关属性的配置,包括整车架构全局的配置方案,还有拆分到各个ECU的一个约束的配置,由DRE交付到供应商或者交付到软件开发团队去约束他们的开发行为,也是作为后续SOA服务部署的一个输入文档。 协议的需求规范文档和项目交付类文档会交付到ECU的控制器供应商或者软件团队进行相关的协议要求的开发,但是软硬件解耦的概念提出后,很多主机厂更倾向于把核心的零部件开发掌握在自己的手中,比如域控网关、中央网关等。 网关实现基于以太网的一些规范,通过OBD口实现智能网关Telnet的登录,通过端口镜像的开和关实现报文从车端到OBD接口的复制,方便工程师实现报文的一些录制,制定OBD接口一些相关的安全访问机制、防火墙机制,车端进行802.1.x的认证,对接入的PC进行安全访问的约束。 相关的ECU实现TCP/IP协议栈、ARP、ICMP、DOIP等协议的开发和实现,去进行TC8的测试以及其他相关测试,去进行反复的迭代和印证。 车载以太网技术生态有了初步的落地之后,然后再开始SOA的落地,架构可以把更多的关注放到SOA本身的实现。 ✦✦ SOA设计开发流程
功能方案这里分为两个过程,一个是自上而下的开发过程,即从功能方案到功能SSTS(子系统技术规范)。 一个是对已有功能服务的转化自下而上的开发过程。整个功能方案中,一部分是服务的设计和实现,功能SSTS(子系统技术规范)还是像传统的架构一样也是需要作为交付文档集中到软件开发。 整个架构设计流程是,通过功能方案的一个大致落地,对服务进行一个抽取形成整车服务的集合,服务集合会包含服务、服务接口大致的梳理和定义,基于整车服务的集合,每个负责服务的Owner对自己负责的服务进行服务规范的梳理。 服务规范是对服务和服务接口的详细描述,定义服务类型、服务依赖关系、服务的错误处理、服务存在应用的场景等。 然后对服务进行一个详细的实现设计,里面包括Service ID,它是服务规范和服务实现技术规范一个过程文档。如果服务涉及到CAN信号的一个转换,需要一个服务对应信号的对照表。 后面整个开发流程是输出相关的SSTS文档,服务Owner会基于集合定义的服务规范,基于定义去填写服务接口需求表文档交付到网络开发,作为网络通信矩阵开发的一个输入,网络开发会交付相关的通信矩阵和相关的ARXML数据库,然后提供到软件开发作为文档的输入。 软件开发需要输入的文档包括服务技术规范,服务SSTS,通信矩阵以及ARXML数据库等。 需要说明的是,服务技术规范跟服务SSTS是要搭配使用的。 由于与网络开发相关的内容比较多,这是单独来看一下,部分截图如下图所示。 接下来,我们对每一个步骤进行稍微详细的分析。 ✦✦ 架构分析 Feature Use Case(可选) Requirement设计 进一步细化Feature列表,对各个Feature进行细节描述,包括法规需求、系统需求、用户自定义需求(值域的要求)等。 如下图所示。 ✦✦ SOA设计之流程指导 ✦✦ SOA设计之服务接口定义 服务实现技术规范 服务实现技术规范是对服务更详细的描述,里面涉及到整个服务接口的逻辑,服务配置字的设计,服务启动停止的条件等。 相关工具链 SOA架构的挑战 |
|