广告
“架构”工作为什么很难做起来？
2019-08-31 10:47:41· 来源：车辆技术
功能架构在中国汽车开发圈子里，是一个很新潮、很前卫、很有前途的岗位！这个开发理念来源于国外的大车企，并被国内很多车企吸收模仿，是我们赶超国际先进水平、
“功能架构”在中国汽车开发圈子里，是一个很新潮、很前卫、很有前途的岗位！这个开发理念来源于国外的大车企，并被国内很多车企吸收模仿，是我们赶超国际先进水平、实现汽车行业弯道超车的方式之一。但是，现实却不是那么乐观……
01、为什么要搞架构？
汽车电子电气系统越来越复杂，已经不能用之前的那种零部件级别的思维来做设计了，必须得有一个角色，站在比零部件高一级的层次上，通盘统筹各种功能去实现。只有这样才能防止零部件各自为政、只顾自己，从而确保整车的设计更加优秀，质量更有保障。
总而言之，“架构”就是为“整车”服务的，是车企为了强化整车方面的工作职能而设立了岗位。
02、“架构”一般都做什么？
这个听起来牛逼哄哄的岗位，一般都做什么呢？
答案也很简单，架构的工作对象就是功能，车上有哪些功能大类，这些功能大类又划分为哪些功能小类，各个功能点跟哪些零部件相关，各个功能如何实现，各个零部件如何交互、如何协同，是需要架构工程师来做的，目的还是更好地实现整车的各种功能。
其实，在“架构工程师”这个岗位诞生之前，这些工作内容也是有的，“功能方案”由各个ECU去“认领”并主导实现。
现在有了“架构工程师”去协调这个事情，但是“功能方案”基本上仍然是由各个零部件去“认领”并承担实现，因为“架构工程师”在国内多数车企里，还不能作为推动力量，去推动方案的设计。
03、“架构”工作为什么那么虚无缥缈？
因为企业虽然配置了“架构工程师”的岗位，但是开发流程上并没有遵循“架构”那一套，也就是说，文档上的技术方案，和软硬件开发测试，脱节了，走的不是同一条路。
这种情况下，架构工程师输出的东西，根本无法闭环，对车辆开发也无法真正起到作用，后续开发环节出现的问题，其他人一般也没有动力去追溯至“架构”环节去寻找原因。
架构输出的一些文件材料，在当下中国的汽车开发流程里，更多的是以“指导文件”的形式存在，而不是“约束文件”，这个很明显就让人觉得可有可无……
04、该怎么办？
架构工作一定要依附于公司级的规范开发流程，没有流程，搞架构就是做样子的。
架构工作要重点关注功能设计实现，功能要划分清楚，要多组织相关的评审讨论，关起门来搞架构工作，是不可能成功的。
架构工作要和总线（还包括低压线束，但是总线和架构关系更密切）搞好关系，甚至毫不客气地说，国内很多企业，就是由做总线设计的人在做功能架构工作，CAN信号的交互，天然具有架构设计的属性，适合从整车层面去统筹功能的设计及实现。
CAN交互的设计，要想做好，也是一个挺麻烦的事情，国内的多数车企，都做得不太好，并且一般而言，主要会有两种形态：如果总线工程师比较强势的话，信号就由总线工程师发布，各个ECU挨个来到总线工程师的座位上，由总线工程师对其进行一对一讨论指导，让ECU工程师看excel（excel文件肯定是不能发的，机密，哈哈），说自己要接收哪些信号、想发哪些信号、有什么意见，之类的，后续总线工程师发布一份打印扫描pdf协议，就算完事了。如果ECU工程师比较强势的话，那么协议一般都在ECU工程师手里，总线工程师不管信号交互，由各个ECU自己去对接讨论，之后总线工程师搜集上来各个ECU手里的协议之后，以整车的名义发布，再做做测试，就算完成工作了。
很显然，上面两种方式都不好，对于前一种，会极大限制ECU工程师的的创造力，并且总线工程师累得要死；对于后一种，那基本上就是放任自流、不管不问了。
我们的“总线架构协同平台”，就能完美地解决这个问题。它可以使信号的交互及讨论，下放到各个ECU之间，由ECU工程师在工具内部自主协商设计，并同时更加强化总线工程师在其中的核心作用，还可以方便地为每个ECU生成不同的协议矩阵以及dbc。
01、为什么要搞架构？
汽车电子电气系统越来越复杂，已经不能用之前的那种零部件级别的思维来做设计了，必须得有一个角色，站在比零部件高一级的层次上，通盘统筹各种功能去实现。只有这样才能防止零部件各自为政、只顾自己，从而确保整车的设计更加优秀，质量更有保障。
总而言之，“架构”就是为“整车”服务的，是车企为了强化整车方面的工作职能而设立了岗位。
02、“架构”一般都做什么？
这个听起来牛逼哄哄的岗位，一般都做什么呢？
答案也很简单，架构的工作对象就是功能，车上有哪些功能大类，这些功能大类又划分为哪些功能小类，各个功能点跟哪些零部件相关，各个功能如何实现，各个零部件如何交互、如何协同，是需要架构工程师来做的，目的还是更好地实现整车的各种功能。
其实，在“架构工程师”这个岗位诞生之前，这些工作内容也是有的，“功能方案”由各个ECU去“认领”并主导实现。
现在有了“架构工程师”去协调这个事情，但是“功能方案”基本上仍然是由各个零部件去“认领”并承担实现，因为“架构工程师”在国内多数车企里，还不能作为推动力量，去推动方案的设计。
03、“架构”工作为什么那么虚无缥缈？
因为企业虽然配置了“架构工程师”的岗位，但是开发流程上并没有遵循“架构”那一套，也就是说，文档上的技术方案，和软硬件开发测试，脱节了，走的不是同一条路。
这种情况下，架构工程师输出的东西，根本无法闭环，对车辆开发也无法真正起到作用，后续开发环节出现的问题，其他人一般也没有动力去追溯至“架构”环节去寻找原因。
架构输出的一些文件材料，在当下中国的汽车开发流程里，更多的是以“指导文件”的形式存在，而不是“约束文件”，这个很明显就让人觉得可有可无……
04、该怎么办？
架构工作一定要依附于公司级的规范开发流程，没有流程，搞架构就是做样子的。
架构工作要重点关注功能设计实现，功能要划分清楚，要多组织相关的评审讨论，关起门来搞架构工作，是不可能成功的。
架构工作要和总线（还包括低压线束，但是总线和架构关系更密切）搞好关系，甚至毫不客气地说，国内很多企业，就是由做总线设计的人在做功能架构工作，CAN信号的交互，天然具有架构设计的属性，适合从整车层面去统筹功能的设计及实现。
CAN交互的设计，要想做好，也是一个挺麻烦的事情，国内的多数车企，都做得不太好，并且一般而言，主要会有两种形态：如果总线工程师比较强势的话，信号就由总线工程师发布，各个ECU挨个来到总线工程师的座位上，由总线工程师对其进行一对一讨论指导，让ECU工程师看excel（excel文件肯定是不能发的，机密，哈哈），说自己要接收哪些信号、想发哪些信号、有什么意见，之类的，后续总线工程师发布一份打印扫描pdf协议，就算完事了。如果ECU工程师比较强势的话，那么协议一般都在ECU工程师手里，总线工程师不管信号交互，由各个ECU自己去对接讨论，之后总线工程师搜集上来各个ECU手里的协议之后，以整车的名义发布，再做做测试，就算完成工作了。
很显然，上面两种方式都不好，对于前一种，会极大限制ECU工程师的的创造力，并且总线工程师累得要死；对于后一种，那基本上就是放任自流、不管不问了。
我们的“总线架构协同平台”，就能完美地解决这个问题。它可以使信号的交互及讨论，下放到各个ECU之间，由ECU工程师在工具内部自主协商设计，并同时更加强化总线工程师在其中的核心作用，还可以方便地为每个ECU生成不同的协议矩阵以及dbc。
广告 
广告
广告
编辑推荐
最新资讯
-
信号分析仪灵敏度的深度解析
2024-12-26 08:48
-
NTN低轨卫星模组及整星电测解决方案
2024-12-26 08:46
-
罗德与施瓦茨推出最新功率传感器，可在高达
2024-12-26 08:46
-
ENCAP2026对前向碰撞避免的要求③
2024-12-26 08:12
-
《智能网联矿卡标准与测评体系》正式启动
2024-12-26 08:11
广告
广告
