• 发文
  • 评论
  • 微博
  • 空间
  • 微信

总线架构第1讲,CAN总线的起源及设计现状

车辆技术 2019-04-13 09:16 发文

本文来自公众号:车辆技术

         CAN总线出生于德国大名鼎鼎的博世公司,是伴随着汽车工业的发展而产生的。上世纪七八十年代,汽车工业蓬勃发展,但是,这个时候,出现了几个非常严重的问题:

         于是,德国人又开挂了。

        1986年,博世在SAE会议上提出了CAN总线标准,紧接着第二年,英特尔和飞利浦分别发布了CAN控制器芯片,自此,CAN总线开启了它汽车通讯领域的辉煌的历史,直至今天,没有任何一种通讯协议能撼动它的地位。

         CAN总线是如何解决师子一号在上面提出的几个弊端的呢?

         自从有了CAN总线,整车电子电控系统就可以进行统筹设计了,“功能交互”成为了一个非常重要的话题,并衍生出了“功能架构设计”这样一个专门的概念。

         架构设计领域有若干专门的工具,比如Vector的Preevision、瑞典的Systemweaver、西门子的Polarion、IBM的DOORS等等。它们的普遍特点就是,很强大,强大到无所不包,什么都能做,除了基本的交互描述、协议DBC之外,甚至连线束长度、重量规格都能做好,有了它,一个汽车公司的很多岗位都可以取消了,几乎所有的工作都可以在它上面搞了(当然,这样一来,架构工作就会很繁重)。

         师子一号对此持保留态度,通过实际观察发现,绝大多数公司的此类架构开发工具,都流于形式,形同摆设,也就一两个人自己用而已,完全没有发挥出集思广益、协同设计的作用。

   师子一号认为,这一类“无所不包、无所不能”的架构工作更倾向于协调整理,适合传统的、已经接近标准化了的汽车功能架构设计,比如燃油车、客车、卡车等。

   对于蓬勃发展的新技术,比如新能源、智能驾驶,这些工具则非常吃力,因为这些新技术自身仍处于持续的变动改进过程中,尤其是很多细节仍然需要推敲、优化,架构工程师可能不是特别熟悉,实用价值不大。至于拿这些定价偏贵的工具去做线束重量仿真,师子一号觉得不实用,而且线束工程师本来就有更好用、更便宜的工具和方法~

         功能架构工作应当侧重于宏观把控,而不是微观设计,过于微观设计,会限制零部件工程师的发挥。功能架构工作应充分发挥各个部件专业人士的专业知识水平,架构居中总体把控,只有这样才能有助于多个部门形成合力、充分发挥各方面的才能,做出更好的车。

架构工作的核心应该是CAN骨干网络设计,并通过CAN骨干网络,追踪车上的传感器、执行器都是谁采集、谁控制、完成什么功能等等。遗憾的是,30多年过去了,部分车企硬生生地把博世当初的一项伟大发明,做成了枯燥乏味、错漏不断、成长受限的体力活,总线工程师奔波辛劳,控制器工程师才能也无法充分发挥……

有鉴于此,我们特意请到了位于上海的交大创新电子实验室团队,他们专注在整车CAN骨干网络及功能架构设计方面,并已经取得了一系列突破性的进展。

接下来将介绍他们在这一领域的最新理念和开发成果,以及他们如何以CAN骨干网络为载体,做电子电控功能结构和功能交互;如何借助于创新性的方法和工具,使总线工程师和控制器工程师都得到巨大的帮助,并最终提升整车的设计质量。

该团队的开源方案采用了“服务器-客户端”的设计模式,服务器安装在一台PC上,客户端安装在各个控制器工程师的电脑上。其工作原理模拟现实工作中工程师之间的交流、思考方式,并把这一切全部程序化、规范化、格式化。

在其客户端,根据具体权限(权限配置是其一大特色,确保够用的同时也不泛滥),各个零部件可以查看所在网络信号或整车信号、可以上传报文(具体操作中,上传的ID应在设置好的ID区间里,且总负债率不能超过某一设定值)、信号,也可以删除报文、信号,也可以评估别的零部件发出来的信号并对其予以接收锁定,锁定之后,发送方就不能修改了,当然,也可以解除锁定。

客户端可以图形化查看报文信号的layout,校对信号排布是否合理,,各个零部件工程师可以自主安排信号位置,还可以根据信号的实时性要求,把实时性相近的信号放在一个报文里。

客户端可以自主导出和自己相关的Excel格式的CAN协议,从这个角度而言,每个客户端导出的Excel协议内容都是不一样的。

据进一步了解,该系统的整体使用方法为“线下交流、线上提交、总线工程师居中管控”,“线下交流”是必要的,因为这和功能讨论评审密切相关。各个零部件工程师自主交流功能所需的信号,需要谁发,然后通过客户端,在系统中对其锁定。自己想要发什么信号,也可以自主提上去,让其他零部件去审核评估。

“总线工程师居中管控”的意思是,该系统有“申请模式”,相比“自由模式”,申请模式下,客户端进行的所有操作,都需要总线工程师在服务器端批准后,才能生效,适合CAN骨干总线的微调优化设计阶段。

师子一号对该方法、理念非常认同,这绝对是一个革命性的方法或者工具,彻底解决整车网络和功能架构设计过程中的混乱、零散、错漏现象,极大增强车企对网络和架构的管控能力。

这种方法一方面增强了总线工程师对骨干总线以及功能架构的管控,另一方面也使总线工程师从信号的细节定义中解放了出来,做一些更有意义的宏观设计,比如功能架构统筹、通讯新技术研究、通信质量分析优化等更专业的工作。同时充分发挥了各个零部件工程师在信号细节上的聪明才智和主动性,非常有利于做出准确率100%、科学合理的CAN网络。

关于服务器端,其管理权属于总线工程师,总线工程师在服务器端所做的大量配置和设置,决定了各个客户端的操作权限,总线工程师也具有整个系统的最高决定权。

据了解,可以支持多个项目同步开发,可以复用已经开发好了的CAN网络,可以一键批量生成dbc(这个太牛了),可以使用超级管理员权限对总线进行微调(比如修改ID、周期等),可以导出整车CAN协议等等。

师子一号了解到该团队目前正在着手做免费的“超级网络”活动,已经在公网服务器上部署该系统,用户只要安装个客户端即可使用,一些用户正在体验使用。用户实际使用的时候,服务器端要部署在公司局域网内部的一台电脑上,并且由总线工程师管理。

广大总线工程师或者控制器工程师可以使用该客户端,扮演其中一个零部件的角色,实际体验一下它带来的便捷高效,以及强大的协同同步设计能力。师子一号看了看,里面的信号的内容还是很有趣的,比如“兔子的颜色,红橙蓝黑”、“豹子奔跑的速度,kmph”,当然,也有一些正儿八经的信号,比如“电机转速”等等。这些都无关设计机密,重点是让广大同行体验一下它是如何确保CAN总线设计严丝合缝、100%不出错的,以及如何让广大客户端发挥才能、增强便利性的。

初步计划,打算同步设计20个项目,每个项目3~4个CAN网段,每个网段大约10个控制器,拓扑图届时也会发布,“线下沟通”的方式也会另行公公布,dbc转换也会阶段性按需要进行。

师子一号在此发起报名体验活动,只需要在后台留言,报上自己的名字(昵称也行)和公司名字即可,并要备注上是控制器工程师还是总线工程师(对于总线工程师,优先分配“网关”角色)。

报名了通过的朋友们,即可获取一个客户端安装包、一份使用指导,您就可以开始体验啦。

后续根据报名情况,该团队会发布一些共性的说明和资料,以及必要的补充(还是在本公众号发布哈)。

        这个设计方法和设计理念,师子一号初次体验之后,非常振奋,它比PREEvision等工具更加专注、更加方便,确实能保证总线设计工作100%不出错,能使总线工程师脱离编辑excel的低效重复性劳动,集中注意力到更加重要、更加有意义的工作内容上去。于此同时,控制器工程师对信号的定义也有用更多的发挥空间,从而使信号的定义更加合理、准确,各个控制器的工程师导出的协议,都是只包含和自己相关的部分,直接发给供应商都是可以的。

        这个系统的最高管理员权限在总线工程师,各个控制器能发那些ID、能操作那些网段、能占多大负载率、是否允许查看全部网络、是否允许导出协议等等所有权限,均由总线工程师设定,这毫无疑问在减轻总线工程师重复劳动量的同时,也大大增强了其对总线设计工作的宏观管控能力。

        据实际使用感受,这个系统的dbc批量转换功能,是师子一号见过的最好用、最成熟的dbc转换工具,一点都不出错,它将excel文件和dbc文件各自的优点都充分发挥了出来,对我们的评审、发布、软件开发和测试工具,都特别有用。

        师子一号也没有忘了打听一下钱的事情,据了解,体验试用永久免费,商用部署目前的政策大概是几万块钱,不限制客户端数量

声明:本文为OFweek维科号作者发布,不代表OFweek维科号立场。如有侵权或其他问题,请及时联系我们举报。
2
评论

评论

    相关阅读

    暂无数据

    车辆技术

    致力于普及、推广、探讨研究汽车电...

    举报文章问题

    ×
    • 营销广告
    • 重复、旧闻
    • 格式问题
    • 低俗
    • 标题夸张
    • 与事实不符
    • 疑似抄袭
    • 我有话要说
    确定 取消

    举报评论问题

    ×
    • 淫秽色情
    • 营销广告
    • 恶意攻击谩骂
    • 我要吐槽
    确定 取消

    用户登录×

    请输入用户名/手机/邮箱

    请输入密码