一图轻松搞懂吉利Basetech之OCC

吉利BaseTech之吾见

正如大家所了解到的那样,吉利作为国内规模较大的主机厂,自从收购了沃尔沃汽车公司,内部也在不断消化来自沃尔沃的Basetech技术。以BaseTech 2.0为例,Basetech的相关技术一方面采用了AUTTOSAR的相关技术概念,同时也带有很多沃尔沃自身诸多的技术要求。

BaseTech你可以直接理解为吉利客户提供给到ECU供应商的基础软件通用技术规范,跟其他主机厂不同的是这一份BaseTech文档汇集了所有的基础软件技术要求,而一般的主机厂则是会按照模块划分来提供不同的基础软件技术要求。

因此很多人在接触吉利BaseTech时会一时难以适应,作为一个从事过BaseTech的开发人员,我从个人实战开发的角度总结了如下BaseTech技术文档的基本特点,同时也可以算作是BaseTech为什么较难开发的原因:

  • 大而全:

    Good:所有基础软件需求基本上都能在BaseTech中找到,颇有一种“BaseTech在手,天下我有”的豪迈气魄!

    Bad:BaseTech文档中包含了并不针对对应ECU的需求,如果阅读不仔细,很容易导致在解读需求时产生歧义或者误解,影响开发效率;

  • 概念新:

    Good:BaseTech文档中存在很多其他主机厂或者AUTOSAR文档中不存在的概念,比如VMM,QCM,CarConfig等基础功能概念等,在文档中你能了解到这些新的基础功能的产生背景及根由,开拓了视野,让你对基础软件技术产生一种全新的认识;

    Bad:正由于较多的新概念,新需求,从而会导致开发过程中需要多次的沟通确认才能够最终冻结其需求。

  • 理论性强:

    Good:BaseTech文档中你会发现读起来很理论,有很多功能的描述很抽象,看完之后还是似懂非懂的感觉,主要是因为其理论性很强,这无疑就会进一步锻炼我们的抽象思维能力,让你深刻理解实现这些基础软件功能的目的所在;

    Bad:由于其理论性强,有些时候你会发现很难在其中找到具体的软件实现方法,往往都是指导思想为主,实现为辅助的方式来呈现,那么毫无疑问就会影响到开发的效率;

按照事不过三的基本原则,以上总结的三个基本特点就是小T个人针对吉利BaseTech文档的基本看法,仅供参考。

正由于上述特点,因此能够完完全全按照BaseTech开发将是一件十分具有挑战性的任务,但是挑战与机遇并存,通过BaseTech的洗礼,相信你会从中获益良多,让你对基础软件的通用技术有个更为深刻的认识,知其然也知其所以然,这才是我们每一个技术人都应当追求的境界!

图解OCC(Operation Cycle Counter)

BaseTech技术万种风情,今天我们仅解读故障管理模块中DTC的OCC(全称为Operation Cycle Counter), 如果你查看AUTOSAR DEM模块的SWS文档,你并不能找全所有的这些OCC的概念定义。

因为这些OCC很多都是BaseTecch中才会存在的内容,以非排放相关的ECU为例,吉利会要求是实现如下OCC1,OCC2,OCC3,OCC4,OCC6这5个OCC。

有关上述5种OCC的BaseTech的原始定义如下图所示, 以便大家对这个OCC有个正确的理解与认识:

小T毕竟能力有限,如果有任何出错的地方,也欢迎多多批评指正。

一图胜千言,本文精华全在于此,Enjoy!
在这里插入图片描述

图1 OCC之吾见

更多精彩内容,欢迎关注公众号“ADAS与ECU之吾见”!
在这里插入图片描述

### 汽车 Basetech 测试的内容 汽车 Basetech 测试是种针对 ECU 的全面测试方法,其目的是验证 ECU 是否能够按照预期功能正常运行并满足特定标准。Basetech 测试涵盖了多种总线类型及其协议栈的功能性和兼容性评估。具体来说,它包括但不限于以下内容: #### 总线通信测试 Basetech 测试广泛覆盖了 CAN(FD)[^2]、LIN[^2]、FlexRay 和 Ethernet 等主流车载总线技术的测试项目。这些测试主要关注于以下几个方面: - **物理层**:检测信号质量、电气特性以及抗干扰能力。 - **数据链路层**:验证帧结构、错误处理机制和流量控制等功能。 - **网络管理**:确保休眠唤醒、同步和其他网络状态转换行为符合规范。 #### 协议致性测试 除了基本的数据传输外,还需要对更高层次的服务进行深入检验,比如诊断服务 (UDS) 及其实现细节中的传输协议 (TP),还有软件在线升级 (OTA) 功能所依赖的刷写流程。另外,在现代车辆架构下越来越重要的端到端保护 (End-to-End Protection, E2E) 技术也被纳入考量范畴之内,用来保障消息的真实性和完整性不受恶意攻击影响。 #### 定制化需求支持 为了适应不同主机厂的具体要求,吉利等厂商还会增加些专有的扩展项作为补充条件之进入整体方案之中,例如 Car Configure Slave 功能实现情况检查;多任务并发执行环境下的资源调度效率测量——即所谓的“队列下载性能表现”评测环节等等 。 这种做法有助于进步提升产品竞争力的同时也促进了整个行业技术水平的进步与发展速度加快进程当中去探索更多可能性领域之外的新机遇所在之处寻找突破口从而取得更大成就目标达成共识之后再继续前进道路上勇往直前不惧挑战困难重重仍坚持到底直至胜利彼岸迎接辉煌明天的到来时刻准备着贡献自己的份力量共同创造美好未来世界而不懈努力奋斗终生无悔青春年华绽放光彩夺目人生画卷之上留下浓墨重彩笔记录属于我们这代人的传奇故事篇章永远铭刻历史长河之中熠熠生辉永不褪色! ```python # 示例代码展示如何通过 Python 实现简单的 CAN 数据解析逻辑 import can def parse_can_message(msg): arbitration_id = msg.arbitration_id data = msg.data if arbitration_id == 0x1A2: # 假设这是某个特定 ID 对应的消息格式 value_1 = int.from_bytes(data[:2], byteorder='big', signed=False) value_2 = float(int.from_bytes(data[2:], byteorder='little')) / 100.0 return {"id": arbitration_id, "value_1": value_1, "value_2": value_2} return None can_bus = can.interface.Bus() message = can_bus.recv() parsed_data = parse_can_message(message) if parsed_data is not None: print(f"Parsed Data: {parsed_data}") else: print("Unsupported message format.") ``` 上述脚本展示了如何利用 `python-can` 库来接收并初步解码条来自 CAN 总线上的报文实例操作演示效果供参考学习之用而已并非实际生产环境中推荐使用的最佳实践方式请务必遵循相关安全指导原则谨慎行事以免造成不必要的损失风险发生几率最小化程度最大化追求极致完美境界永不停歇脚步持续改进优化自我超越极限不断攀登高峰向着梦想方向坚定前行直到最终成功抵达目的地为止绝不轻言放弃任何次机会尝试新鲜事物体验未知冒险旅程开启全新视野格局拓展无限可能空间尽情享受生活带来的每份惊喜礼物吧朋友们加油干起来让我们起携手共创更加灿烂辉煌的美好明天吧!
评论 10
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

汽车小T

感谢打赏,我会继续努力奉献精彩

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值