静虚待令，有物混成

原创 舱驾-开放联盟

COVESA全球联盟2025年5月召开了成员会议（会议记录见其官网Wiki），聚焦汽车开源技术发展。该组织与Eclipse SDV（待补充）同为推动汽车软件标准化的重要开源社区。COVESA Wiki作为核心知识库，汇总了各类技术文档和项目进展，而Eclipse基金会旗下SDV项目则与之形成技术互补，共同构建智能汽车开源生态。（99字）

原创 舱驾融合-新国标要求

GB/T32960-2025和GB45672-2025标准规定了车载事故紧急呼叫系统的技术要求。硬件方面要求：工作温度范围-40~95℃（乘客舱太阳直射处）或-40~90℃（其他位置）；支持北斗优先或单模定位；必须支持TD-LTE/FDD-LTE多个频段；需配置备用天线和电池；安全等级需满足GM/T0008-2级或EAL4+要求。标准还规定了工作环境相对湿度为25~75%（常温条件）。软件部分内容待补充。

原创 舱驾融合-智能体

Google智能体技术文档与配套指南现已开放下载。核心文档《GoogleAgents》提供技术框架说明，配套《GoogleAgentsCompanion》则包含实用操作指引。开发者可通过Google Drive获取主文件，配套指南可从指定网站下载。两文件协同使用可帮助开发者快速掌握Google智能体开发技术。

原创 舱驾操作系统架构规划

随着汽车行业向软件定义汽车转型，整车电子架构（EEA）正经历从分布式向域控融合演进。当前车用软件平台主要采用Hypervisor（Q+A/L+A架构）或Hypervisorless方案，生态构建涵盖自研与第三方（如GAS、哈曼等）。基于"五看三定"方法论分析，舱驾融合成为趋势，需重点布局中控IVI、仪表、HUD等核心座舱系统，以及显示、多媒体、Tbox等20余个子系统。未来汽车软件开发需构建硬件隔离、功能安全的平台架构，同时平衡自主创新与生态合作，实现软硬件协同发展。

原创 01-座舱/舱驾-传感器

汽车发展朝着智能汽车方向快速演进，越来越多传感器被标准化集成到座舱中，常见的有IMU、地磁、气压计、光感、温度传感器等；有三轴、六轴、九轴、十轴等规格。

原创 01-AAOS 使用 GAS 还是不使用 GAS

谷歌开发的开源操作系统和软件平台。它广泛应用于手机和其他移动设备。针对汽车使用优化的开源操作系统。由 Google开发和维护。一项允许您在汽车信息娱乐系统内使用 Android 手机的技术。如果汽车支持 Android Auto，您只需连接手机（通过电缆或蓝牙）。然后，汽车屏幕上会出现一个附加菜单。它类似于Apple CarPlay和MirrorLink等技术Google 汽车服务 (GAS)AAOS 的可选附加组件，提供和。GAS 必须获得许可，因此会给汽车制造商带来额外成本。

原创 01-座舱平台自研选型思考

近年来，随着汽车“新四化”浪潮的兴起，软件定义汽车已成为产业共识，将深度参与到整个汽车的定义、开发验证销售以及服务全过程。一方面确保软件可升级，跨车型、软件甚至跨车企软件重用。另一方面对于硬来讲，要做到可扩展、可更换，甚至做到传感器的即插用，让消费者享受到常用常新汽车体验。智能座舱作为软件定义汽车，以及人机交互智能化的关键域，备受重视。座舱硬件平台繁多，有X86架构的AMD,以及intel平台方案，又有ARM架构的高通、瑞萨、三星等平台方案；又如驾舱合一的平台方案：SA8775。我们该选择？选择一条符合。

原创 座舱软件开发“道与术”

仅仅个人归纳见解，欢迎专家莅临指导。

原创 TI SERDES Roadmap

显示输出： 视频输入：

原创 座舱出海认证相关

转载 Android 共享系统映像[转]

为检查修改后的文件，OEM 可以使用工具，并将 AOSP GSI 与 OEM GSI 进行比较。从 AOSP 启动目标获取 AOSP GSI。通过定期使用allowlist参数运行工具，您可以监控允许列表之外的差异。如此，您就无需对 OEM GSI 进行其他修改。图 5.定义允许列表，以缩短 OEM GSI 中的已修改文件列表为避免在/system分区中执行任何特定于产品的更改并定义 OEM GSI，OEM 可以使用名为的 makefile 宏，来阻止在调用该宏后声明任何系统模块。请参阅。

转载 Android GRF 更新策略简析[转]

GRF 无疑减轻了上游 SoC 供应商的维护压力，在 GRF 之前，高通承诺为 Vendor 提供 N+2 及 3 年的安全更新支持，而 GRF 至少能为 OEM 厂商提供绕开上游 SoC 供应商的机会，独立提供 N+3 的大版本更新（这也是站在 Android 维护的角度，我不推荐任何骁龙 870 新机的原因，由于反复鞭尸炒冷饭，可预见今年发布的 870 新机即便定价没怎么降，各种维护支持都将显著比同期中高端 SoC 来得更差）对于刚刚发布的骁龙 8 Gen 2 来说，自然也支持 GRF 策略。

原创 01-灵魂一问：智能网联汽车域控SOA如何做？

/TODO。

原创 03-Unix Socket demo

【代码】03-Unix Socket demo。

原创 01-EEA电子电器架构

采用汽车分布式ECU架构，各个功能由很多单一的ECU提供硬件-软件解决方案（如发动机、变速箱、仪表盘或信息娱乐系统等），这些功能性ECU集群组合在一起，通过CAN、LIN或FlexRay等传统总线系统连接。通过EEA的设计，可将动力总成、驱动信息、娱乐信息等车身信息转化为实际的电源分配的物理布局、信号网络、数据网络、诊断、容错、能量管理等的电子电气解决方案。电子架构是一个贯穿系统开发、网络开发、功能开发、电路设计、软硬件开发的综合性工作，需要清晰的开发流程来定义指责、交付物、时间节点。

原创 01-SDV软件定义汽车思考

随着汽车产业“新四化”(电动化、网联化、智能化、共享化)的加速推动，智能汽车已成为各国科技发展战略重点，在社会数字化转型的浪潮下逐渐形成跨领域协作、多技术融合的汽车产业新赛道。软件定义汽车已成为行业趋势与共识，在此影响下汽车产业正迎来全面重构，本轮重构将给汽车产业带来全方位的根本性改变，以机械硬件主导的传统汽车将演变为以软件主导、数据驱动和软硬融合的智能移动终端，并将由此催生出与此前完全不同供应链模式和产业生态圈。

原创 01-SDV全域OS研发思考

近年来，随着汽车“新四化”浪潮的兴起，软件定义已成为产业共识，将深度参与到整个汽车的定义、开发验证销售以及服务全过程。一方面确保软件可升级，跨车型、软件甚至跨车企软件重用。另一方面对于硬来讲，要做到可扩展、可更换，甚至做到的即插用，让消费者享受到常用常新汽车体验。汽车软件涉及车身域-ECU、VCU，智能驾驶，仪表、座舱、Tbox等。如果每个域都有不同的OS，以及架构，那么开发人员是非常庞大的，而且存在对技术系统理解差异，产生较大沟通以及开发成本。在SDV思想浪潮的冲击下，怎么基于SDV思想低成本落实。

原创 03-Android App logger策略

略。

转载 深度解析 AWS Firecracker 原理篇 – 虚拟化与容器运行时技术[转]

AWS Firecracker是一款由 AWS开源的轻量级虚拟化运行环境，客户可以在 AWS 云上和本地环境中使用它。Firecracker MicroVM 同时具备传统虚拟机的安全性和工作负载隔离能力以及容器的速度和资源利用率。运行在为 Firecracker 优化过的 Amazon 裸金属 EC2 服务器上的 MicroVM是多租户容器服务的理想选择，可以为最新的微服务或无服务器架构的现代应用提供方便、敏捷的开发和部署环境。

原创 01-学科制思考

新发展格局下，科技创新已成为企业生存和发展的关键，而人才的专业能力构成企业的核心竞争力。企业规模不断壮大、人员质量不断提高，给企业注入新鲜血液的同时也带来了更多人才管理与发展上的挑战。如何科学、合理地对人才专业能力进行评价，如何牵引人才进行自主能力提升，如何建设有效的培训体系帮助人才进行能力提升，成为亟待解决的问题。它不仅关系着人才的保留与发展，更是直接关系企业的可持续发展和商业成功。

原创 01-FMEA方法论

FMEA（Failure mode and effects analysis，故障模式与影响分析）又称为失效模式与后果分析、失效模式与效应分析、故障模式与后果分析等，专栏采用“”，因为这个中文翻译更加符合可用性的语境。FMEA 是一种在各行各业都有广泛应用的可用性分析方法，通过对系统范围内潜在的故障模式加以分析，并按照严重程度进行分类，以确定失效对于系统的最终影响。FMEA 最早是在美国军方开始应用的，20 世纪 40 年代后期，美国空军正式采用了 FMEA。

转载 传统车企和互联网造车在整车os开发上的不同与短板[转]

但是ESP可以向SOA平台开放出哪些功能，比如切换驾驶模式，无论是冰面模式、雪地模式，还是调整悬挂的舒适型，这部分的整体模式控制是可以开放到SOA平台上的，由上层的应用开发者进行跨域功能的协调，这是我们第一个观点。最后一点的角度来讲生态，也是我们最大的优势云原生，依托于几十年互联网IT和软件行业生态圈，无论是工具链的选择，还是工程师的整体人才储备，从数量来说，包括从成熟度，都比传统汽车软件的数量级要大2至3个数量级，构建将来整车操作系统的生态圈，这是我们最方便、最可以落地的技术路线的选择。

原创 01-6W2H方法

法是我们制定策略时的黄金策略，并有不同的衍生版本，比如5W1H、3W1H等等，都是结合实际情况进行的剪裁运用。通过6W2H思想方法来进行研发管理以及问题分析，具备清晰的思路。

原创 座舱开发的“道”与“术”

近年来，随着汽车“新四化”浪潮的兴起，软件定义已成为产业共识，将深度参与到整个汽车的定义、开发验证销售以及服务全过程。一方面确保软件可升级，跨车型、软件甚至跨车企软件重用。另一方面对于硬来讲，要做到可扩展、可更换，甚至做到传感器的即插用，让消费者享受到常用常新汽车体验。智能座舱作为软件定义汽车，以及人机交互智能化的关键域，备受重视。那么如何开发智能座舱项目？老子说 “有道无术，术尚可求；有术无道，止于术”，对于软件开发人员，做到“道”与“术”结合，大处着眼，小处着手。直接上脑图，仅仅是记录个人思想。

原创 01-SOA 通讯中间件(Middleware)任重道远

路对了，不怕远

原创 01-ASPICE体系知识

/TODO任何事情具备多面性。比如古代帝王术就是集成法家与儒家思想，外行儒家，内行法家。同样，无论是军事，还是商业，都讲究奇正合一，哈哈那么汽车电子行业软件开发，也可以将ASPICE体系与DevOps兼得，既保证开发效率，又保证了开发品质。ASPICE。

原创 03-Android JNI/Native数据传输策略之java class(对象Object)

举一反三，当前只拿int、short、int[]、short[]举例。/*** @description: JNI对象传输测试*/

原创 01-Android 序列化与反序列化

在日常开发过程中，经常遇到程序读取文件，将文件数据转换为对象，程序通过对象传输数据，或者通过对象读取数据。同时也会经常遇到对象数据写入文件操作。如果采用常规的文件读写，然后再进行赋值；那么将耗费很多时间码代码实现，同时，如果在文件参数较多的情况下，采用常规操作将是一个重大工程量。囧o(╯□╰)o那么软件前辈经过日夜奋进，不断创新，总结开发出很多优秀的反序列化及序列化工具/sdk/库，如下图所示通过序列化&反序列化sdk，大大提高软件操作文件效率。

原创 01-关于QNX network网络那些事情

编译socket 可执行程序，经常遇到bind失败，提示permission。涉及网络，还是得io-pkt处理下。

原创 01-死磕QNX someip

无

原创 01-ECU和域控制器(摘)

电子电路相对于机械控制的优点在于精细化和自动化，是智能化的基础。首先，要精细化的控制，就需要在传统机械设备上引入电子电路。1968 年电子设备首次出现在汽车中，当时大众汽车在大众1600轿车的发动机中安装了电子控制单元 (ECU)，以帮助控制燃油喷射。

原创 01-SOA到底是什么？

AP是Autosar Adaptive Platform，它是支持面向服务体系结构即SOA（Service-Oriented-Architecture）。AP主要提供高性能计算和通信机制，并提供灵活的软件配置，如OTA技术。

原创 01-基于SOA架构someip 开发-QNX平台开发

软件定义汽车，智能网联汽车作为未来汽车发展的主流方向。SOME/IP 是一个汽车的中间件解决方案，可用于控制消息。从一开始，它的设计就是为了完美地适应不同尺寸和不同操作系统的设备。这包括小型设备，如相机、AUTOSAR设备，以及头部单元或远程信息处理设备。同时还确保了SOME/IP支持信息娱乐域以及车内其他域的功能，从而使SOME/IP可以用于多数替换场景以及更传统的CAN场景，在智能网联汽车，面向服务开发SOA架构思想环境下，SOME/IP扮演着非常重要的角色--通信。

原创 01-基于SOA架构someip 开发-Boost-1.55.0 QNX交叉编译

qcc编译存在lisence过期问题，因此采用gcc交叉编译//TODO。

原创 10-QNX与Android双系统通讯之FDBUS(2)

/TODO。

原创 01-基于SOA架构someip 开发-Linux开发环境搭建

SOME/IP 是一个汽车的中间件解决方案，可用于控制消息。从一开始，它的设计就是为了完美地适应不同尺寸和不同操作系统的设备。这包括小型设备，如相机、AUTOSAR设备，以及头部单元或远程信息处理设备。同时还确保了SOME/IP支持信息娱乐域以及车内其他域的功能，从而使SOME/IP可以用于多数替换场景以及更传统的CAN场景，在智能网联汽车，面向服务开发SOA架构思想环境下，SOME/IP扮演着非常重要的角色--通信。

原创 01-微服务探讨(摘)

微服务架构即是采用一组小服务来构建应用的方法。每个服务运行在独立的进程中，不同服务通过一些轻量级交互机制来通信， 例如 RPC、HTTP 等。服务围绕业务能力来构建，并依赖自动部署机制来独立部署。虽然勾勒出了微服务的一些关键概念：小、独立进程、自动化，但是这样的定义还是太抽象，太务虚，很难落地。一解释以为懂了，一问还是不知道，一讨论就打架。换句话说，就是*道可道，非常道*。从Martin作为ThoughtWorks公司的首席科学家的角度来看，他把微服务“炒”起来了，如果像12-Factor。

原创 10-QNX与Android双系统通讯之FDBUS(1)

综上，跨系统通讯FDBUS Demo例程算是基本掌握了。后面就是如何在FDBUS基础上进行二次开发，定制化开发，让它进化满足产品要求。

原创 FDbus NDK以及QNX交叉编译

fdbus 可以这讲，就是一个定制化的RPC，可以用于进程间通信，以及双系统间通信。TODO。

原创 Protobuf NDK以及QNX交叉编译

Protobuf 用处很广，尤其是通讯数据序列化，反序列化。TODO。