自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(16)
  • 收藏
  • 关注

原创 一份汽车软件需求的生成过程

用例也是需求,但它作为承接系统需求和架构(如MBSE里的Use Case图)的环节,会写得。然后,在有某条需求的配置处标记yes,或者可标定或软件参数化的部分也可标记具体参数值。功能需求是最名正言顺的需求,描述了由某个软件组件实现的功能,并且从软件外部看,它是。至此,一份软件需求文档正式生成。所以,尤其我们有需求管理工具支持时,最好拆分多个属性,这里提供4个最基本的。比如,用户输入账号密码登录,如通过验证,系统进入主页,否则,提示错误。软件开发是个团队合作的过程,而需求更是几乎所有人都要关注的,我们要让。

2023-11-23 19:25:15 69

原创 如何评价智能座舱的好坏之指标拆分?

智慧服务实际上是有一些比较实用的功能的,常用的有后视镜自动伸展、离车自动落锁、座椅记忆等,但这部分前装率较高,各家的区分度不高,所以一级指标中占比最低(10%)。不过呢,规则里的权重仅有5%,或许是考虑到比较成熟,没有区分度。全景环视明显拔得头筹,占比85%,这对于我这种没有倒车影像不敢倒车的人,举双手赞成,但还是要看其效果,比如,现在,测评规则的颁布实际上也让我们看到,智能座舱的技术方案正走向成熟,并将走进规范化运作。,占比 60%,这与我们对座舱最直接的认知符合,

2023-11-23 19:24:37 70

原创 汽车软件开发模式的7个特点

原本呢,这部分算是传统汽车暨三大件被绕过后还剩余的技术门槛,但是,新势力进来后,先是一波高薪,两三年就培养出一大批功能安全工程师,,如发动机控制、电机控制、刹车控制、电子助力转向控制、车身稳定控制系统ESP、混动系统控制、安全气囊控制、电池热管理等。一阵寒意后,功能安全?,如网关、照明控制、雨刮控制、车门车窗控制、无钥匙启动、天窗控制、座椅记忆控制、后视镜控制、功放控制。是不同性质的要求,但都是期望将行业的躁动按住一点,将开发的混乱规范一点,将安全的地位拔高一点,但是。

2023-11-23 19:23:17 46

原创 如何区分汽车ECU的ABCD样?

对于软件开发团队而言,需求都已经执行,子功能都已经验证完毕,即使仍然有可知bug(没有bug的软件是不存在的),也不严重,相关方都能够达成偏差许可。,比如,外观确认、结构匹配、包装开发、HIL(Hardware in Loop,硬件在环)测试、台架测试或其他基本工作原理确认等,肯定。,但还缺最后一步——客户确认(validation),如整车或产线确认,如果发现了问题,或许还需要一个迭代。在这里,我们讲个带有软件的样件成熟度的划分,但会同时涉及机械及软硬件状态的描述,即ABCD样件。

2023-11-23 19:22:25 59

原创 评价ASIL D软件代码的11个指标

在处理错误或跳出多层循环时,有很直接的效果,但非逻辑性的跳转会让代码很难理解、出了错误也很难追踪。存在的参数越多,就越容易在调用函数时出错,比如,参数顺序错误。代码也是一样,太长的代码行会明显增加阅读代码的难度,很现实的问题是,本文基于嵌入式ASIL D产品的开发经验和行业标准,分享了11个常用的代码指标及推荐限值,供参考。出口点通常是return语句,所以我们也建议尽量减少其数量,比如,一个函数的return维持在。在保证合理的逻辑、换行和缩进的前提下,要尽可能将长代码拆分。)时,就会发生嵌套,每。

2023-11-23 19:21:04 45

原创 汽车软件单元测试的要点与意义

主要包括控制流分析(如语句条件分支、循环迭代次数)、数据流分析(如变量值的传递)、代码复杂性(如圈复杂度、路径长度)、依赖关系(如函数之间的调用、模块之间的依赖)等。通常,基础的覆盖度(如语句覆盖和分支覆盖)是必要的起点,而在需要更高可靠性和安全性的项目中,可能会选择更严格的MC/DC覆盖度,比如,涉及ASIL D的模块。理论上,对于手写代码的合理性与正确性,他人及更有经验的他人去检查一遍,有一定的意义,甚至某些案例下,会胜过后期测试。但有时候,涉及到第三方标准库时,就无法按照这个规则执行了,

2023-10-26 22:10:19 61 1

原创 如何用大白话写一篇让人愿意看的技术文章?

CPU诞生于大规模集成电路时代,早期主要以4位和8位微处理器为代表,但随着技术的演进,其架构设计和集成电路工艺也都在不断发展,时至今日,已经发展为以多核为特点的高性能处理器,比如,英特尔和AMD系列。实际上,我上面这段话就用了这个技巧,开始时,“类似”这里用的是“相近”,但后面依次有“近义词”和“比较近”,“近”字就重复太多了,所以改为“类似”,这样读起来的感觉会不会好一些?比如,大力发挥管理层的作用,积极主动加强业务优化,千方百计落实政策,这三句话,没有主语,没有方案,喊口号都没有回音。

2023-10-26 22:01:57 52 1

原创 评价ASIL D软件代码的11个指标

在处理错误或跳出多层循环时,有很直接的效果,但非逻辑性的跳转会让代码很难理解、出了错误也很难追踪。存在的参数越多,就越容易在调用函数时出错,比如,参数顺序错误。代码也是一样,太长的代码行会明显增加阅读代码的难度,很现实的问题是,本文基于嵌入式ASIL D产品的开发经验和行业标准,分享了11个常用的代码指标及推荐限值,供参考。出口点通常是return语句,所以我们也建议尽量减少其数量,比如,一个函数的return维持在。在保证合理的逻辑、换行和缩进的前提下,要尽可能将长代码拆分。)时,就会发生嵌套,每。

2023-10-26 22:01:07 72 1

原创 汽车视角下看DevOps的内核和适用性

另外,我们也可以放大汽车行业Operation的范围,比如,将验收部门理解为Operation,而后去尝试适配DevOps的理念或实践。这里必然要以务虚的文化作为起步,但我们又不想谈文化,因为文化是所有人都知道且认同,但又不知所云或不以为然的东西。文字解决不了这种问题。当然,如果往长远预想,OTA足够成熟自由后,开发阶段的变更就能够及时持续体现在消费者车上,那样,才更接近IT DevOps的场景。通常,我们要建立全面的监控系统,监控各个环节的数据表现与日志记录等,一旦生产环境发生意外,能够第一时间识别。

2023-09-28 10:20:33 27

原创 汽车软件集成的5个层次

这种分工与标准化的好处不言自明,但也增加了很多集成点,集成点多了就会造成沟通协调复杂或者解决方案整合困难等弊端,而这也是我们做汽车软件要充分考量的。对于软件来说,尤其要考虑对手件联调,越来越多的电子功能需要多模块协同,最常见的诊断、通信问题就是该环节频繁识别出来的。二来呢,这些都属于技术特性,技术差异点只能说明汽车的“软件”和互联网的“软件”,而非“汽车软件”与“互联网软件”。传统汽车的各个子系统或者域通常是分离的,相互之间大体隔绝,所以涉及到的是装配,而非集成这个概念。

2023-09-28 10:19:01 83

原创 一次十分恶劣的用车经历后对产品体验的进一步理解

我以前调研过某款老牌合资车和某款新势力车型电芯诊断逻辑的功能安全策略(数据已脱敏,只描述逻辑),前者选择的是电芯丢失通讯10s就会报故障灯,电芯丢失通讯30s,强制下电,这是一种安全保障机制,但给用户非常差的体验和低质量的观感,而后者的诊断时间设置为2分钟,也仅仅是亮起故障灯,也就是说,你在路上狂奔,但电池状态2分钟内是未知的。好不容易弄好,再去扫码充电,泛黄的电子显示屏显示了一个隐约的二维码,但碍于阳光直射,它也是犹抱琵琶、扭扭捏捏,让我左扫右扫扫不上,做贼一样,用胳膊挡着太阳,才算扫成功。

2023-09-28 10:14:01 37

原创 再看敏捷(SAFe)对汽车行业的价值

话没毛病,毛病是,我们经常会看到一种本该令人匪夷所思却又被教育“年轻人不要太较真"的现象,比如,A团队正在做一件B团队半年前已经证明没意义的事,而C团队正在用另一种思路做同样的事,但是,很有默契的是,ABC这三个团队都悄悄地等待一鸣惊人,见面时还要微笑致意,我啥都没干。反复纠缠之下,我是对小团队小规模敏捷没啥耐心了,而正在我与敏捷彻底决裂的最后关口,最近,参与到了一个SAFe转型项目,些许点滴让我意识到,似乎这些因素确实会对大团队汽车软件开发有些益处,这给我带来了兴致。再去沟通,告诉我们两周后才接新需求。

2023-09-28 10:06:27 92

原创 有关复杂汽车软件bug管理的思考与探索

这种不能自拔有两层意思,第一层是难以自拔,因为尤其在后期,大多数人的大多数精力都集中在bug上,写bug,测bug,分bug,数bug,解bug,而第二层是不愿自拔,毕竟,追着条理分明的bug去做事,相对简单,也相对体现价值......:现在很多汽车软件都是多方跨组织协同开发的,如果站在供应链的维度看一个复杂问题,就有必要知道问题所处的组织层级,是主机厂,是Ter1,是第三方软件,还是芯片,或者软件平台提供方。其中,必然少不了bug,甚至在项目中后期,说bug牵引着项目的运转,都不算过分。

2023-09-28 10:05:31 55

原创 汽车ECU测试中的几个共性问题

最近的工作需要经常和测试打交道,但我并非这个细分领域的行家,看着几千条测试用例和五花八门的测试设备与工具,以及工程师展示的繁复曲线与图表,着实有些眼花缭乱,没太看懂,不由得陷入了深深的思索......原因是老师说的一句话,“话我照讲,实验你们照做,但你们多年后肯定记不住我们今天做了什么,只要记住一点,焦利氏称是测微小力的......”老师的反向操作倒也是6,不肖弟子把老师是谁都忘了,系统测试要尽量真实,真实的线束,真实的负载等。测试是个非常庞杂的课题,值得反复研究,限于精力与时间,本文简单总结,点到为止。

2023-09-28 10:04:54 26

原创 汽车的用户体验具体是在讲什么?

由于座舱涉及的安全与法规问题较少,对车圈外来者,算是软柿子,再加上种种其他因素,座舱概念铺天盖地铺展开来,对应地,大众关注点逐渐转变为用户的整体感受,开发人员也开始跳出独立的解决方案,放在整车系统层面去横向拉通。可真是,士别三日,当刮目相待。当然,黑屏死机,大家都知道不好,但死多久,啥时候黑,才算是真不好,也说不清楚。很明显,这些看得见的东西都是用了心、花了钱的,随后,那是否有类似0.02个PPM失效的疑问,或者同等价位下汽车各属性必然顾此失彼的现实,于我确实也不明显、不敏感了,不可见的东西,谁知道呢?

2023-09-28 10:02:14 78

原创 深度解读李想产品课,以“理想”为镜

这个挑战对于新旧势力也是不一样的,新势力是包工头新拉的施工队,从打地基开始盖楼,传统车企是站在旧式筒子楼上,暂时领先,但看着CBD的快速追赶的态势,以及自己根基不稳而又不得不面临各种泥工、瓦工、水电工的利益较量的现状,欲说还休,欲说还休啊,只能尽力转型。直到最近,李想推出《李想·产品实战16讲》,我花了99,仔细听了几遍,算是有了更多的认识,放下傲慢与偏见,我们确实是有一些可以向理想学习的地方,比如,用户体验、流程建设、人员融合等。我自然知道,从实际利益上看,我是受损了,但我花钱,我愿意。

2023-09-28 00:06:56 452

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除