All Posts

曲奇泡芙一年回顾

2019年3月10号开始,写【曲奇泡芙】这个公众号至今也将近快有一年了,期间断断续续更新了21篇原创内容。算了一下平均约17天产一篇,空的时候一个星期写一篇,忙的时候3个月写一篇。个人号更新比较低频,但写内容的初衷没有变,希望学过的东西有所累积,也希望该号能有持续的技术干货输出。另外后台持续增长的关注数和源源不断的文章打赏也是支持本号继续写下去的一个动力:D。 文章发布在公众号之外我也会维护在自己的博客网站(weng.ai)上,我有个脚本负责自动同步发布在微信公众号上的文章到自己的网站上。网站的好处是你可以有公众号之外的功能,比如给文章添加标签索引,方便归类整理浏览。为了避免人工参与,我有个算法来给文章生成关键词标签。 如下图,是算法生成的过去一年21篇发文的标签图,基本体现了这个公众号过去一年的内容主题。 历史发文标签回顾 以下为过去21篇发文的具体标签生成,基本上除了个别标红的奇怪词语作为标签不太合适,以及部分同义词没有被归为同类,基本能满足需要。有写公众号的同学也欢迎把你的号在后台发我,帮你生成过去一年文章的标签图( 如 上 图 )。 聊起车联网技术时,我们可能想说什么 标签:车联网,技术,架构,车辆,自动驾驶 汽车电子架构,进化或改革? 标签:汽车电子架构,改革,架构,功能,汽车 从AVB到TSN - 时效性网络来了 标签:TSN,时效性,AVB,网络,传输 特斯拉Model 3 Key Card里的黑科技 标签:特斯拉,科技,卡片,智能卡,NFC 端与云的融合 标签:融合,服务,云端,嵌入式,车载 停车场寻车难? 蓝牙5.

GraphQL + Space Cloud 简化你的API设计

服务端API的设计与开发,为客户端提供产品业务所需要的各种功能和数据接口。随着APP产品的迭代更新,APP Server提供的接口往往也会进行多个版本的迭代更新 。 如何优雅的维护接口的稳定性,设计扩展性满足将来一定的业务需求变更,一直是从事服务端接口开发工程师需要不断思考的问题。 特别的,当你同一个服务的接口需要服务于多个需求不尽相同的客户端时,你的接口设计工作会变得尤其重要: 你可能会开始为接口提供各种option,以支持不同的客户端接入使用不同的option满足不同的需求; 你可能会将数据接口粒度拆分得更小,以支持不同客户端组合不同的API得到自己需要的数据; 你可能还需要提供通用的batch批量请求接口,以解决客户端通过蜂窝网络远程调用多个数据接口延时增大的问题,又或者为某个客户端接入量身定制满足需要的接口; 之所以会产生这样的接口维护成本,一个原因在于这里API接口的设计承担了数据表示的职责:为前端的UI/UX提供展现所需要的数据。比如APP上的个人中心页面,UI/UX需要展现昵称,头像,性别的数据,这是一个来自UI/UX对数据接口返回的需求。 有没有可能将来自UI/UX的需求尽量控制在UI/UX的实现端(客户端)从而减少UI展示层的逻辑变化的复杂度对后端接口的影响呢? GraphQL 专注于数据建模 2012年Facebook移动端从H5改用IOS原生应用重新开发时遇到了类似的问题,新的APP产品设计使得原来的很多REST API不再适用或者使用过滤繁琐。解决这一问题,Facebook在接入层添加了一层称为GraphQL的查询语言。并于2015年,发布了GraphQL的规范及其javascript版本的参考实现。 如果说传统的REST接口类似一个售货机,每次按一个按钮获得一个对应的货物,需要5个不同货物你需要按5下,那么GraphQL仿佛一个智能按钮,可以让你通过表达你的需求一次获得需要的所有货物。 GraphQL让服务的设计者可以专注于数据建模,而非接口的数据表示和组织。 服务的设计者完成数据建模定义好服务的数据能力,服务使用者可以通过GraphQL表达自己的需求来按需得到自己需要的数据,不多也不少。其中GraphQL中的Graph意指数据模型中数据之间的关联关系类似于连接不同节点的边构成一个图。 具体的,GraphQL有3个主要组成部分: Queries:客户端的请求即一个查询; Resolvers:服务端通过resolver的方式告诉GraphQL每个查询字段的数据如何获取;这也使得API数据模型和后端的数据库表结构/外部存储得以解耦; Schema:描述服务端的能力的数据模型,客户端基于这个数据模型进行查询操作。 GraphQL通过一个统一的HTTP API接口来传递数据:通过文本描述数据请求需求,接口返回匹配需求的数据。如下图,行1~8为客户端请求的GraphQL形式的需求描述,该请求查询id为1的作者的名字,以及要求返回其关联的id为5的一本书的标题;行10~21为对应的匹配客户端数据需求的返回。 在这里我们可以看到,客户端有了表达自身数据需求的灵活性。 类似的GraphQL中也定义了对数据进行修改的语法。 从2016年开始,随着GraphQL在不同编程语言上的生态的丰富,这项技术开始被Twitter,Yelp,Airbnb等公司应用于自己的产品中,如下图目前GraphQL已经在近100家不同规模的企业中开始使用。 Space Cloud 加速API开发 如果说GraphQL做的事情是把服务端提供的接口职责与使用者划分清楚,那么Space Cloud想做的事情是在这个职责范围内如何让开发工作可以更快的完成。 如下图,Space Cloud是一个新的API接入层解决方案,它可以对接后端不同类型的数据库,微服务以及文件存储,为前端提供统一的GraphQL接口。Space Cloud使得对数据库进行CRUD(增删改查)操作的接口可以被快速实现,提供对接微服务接口的能力使得系统原有REST风格的接口可以被组装并以GraphQL接口的形式统一对外提供。 具体的,Space Cloud服务部署后,提供了一个管理界面(Misson Control)。如下图,在管理界面上新建项目后,你可以在界面上新建数据库连接(提供数据库实例的连接信息),并通过运行GraphQL的方式新建数据表。 如上图的GraphQL往数据库中创建了trainer & pokemon两张表,在ID上建立了外键关联。与此同时,在未写任何代码的条件下通过GraphQL接口对外提供了这两个数据模型的增删查改接口能力。你可以开始使用GraphQL接口进行查询数据/插入数据等,Space Cloud为你实现了背后的数据resolver逻辑。比如下面是一个连表查询的操作及其返回的结果(注意,这里你并不需要写连表查询的SQL语句)。 通常来说,我们有很多接口逻辑不是简单的数据库增删改查可以完成,这种情况Space Cloud提供了微服务接口接入的功能。类似的,你可以在Space Cloud的管理界面上声明你的REST API的接口信息(请求路径,参数,响应格式等)。比如你有两个微服务的HTTP接口: /add接口:接收两个参数,返回两个数的和; /double接口:接收一个参数,返回其乘以2的值; 在完成接口的声明后,你就自动的获得了通过GraphQL访问接口能力,同样的不需要任何编程。而借助与GraphQL的并行和嵌套语法,你自动的获得了将微服务与数据库操作进行组合或者并行查询的能力。比如以下的查询,客户端可以在一次请求中,并行地完成某个数据的查询操作以及对两个微服务接口的调用; 再比如以下的查询,客户端可以在一次请求中,完成对某个数据 的查询操作并对其返回结果中的某个字段调用另一个微服务接口(/double)进行加工处理。 而这些功能的实现,还未进行太多的编码工作,是不是很酷? Space Cloud基于Apache 2.

vsomeip - GENIVI的SOME/IP开源实现

“Color is a power which directly influences the soul.” 车载以太网作为主干的整车网络拓扑架构中,以太网节点(如域控制器)之间进行数据通讯需要协商使用共同的应用层协议。在车载场景中的以太网应用中,根据不同的应用特点适用不同的应用层协议,如用于ECU诊断和刷写的DoIP(Diagnostics over Internet Protocol)协议,用于消息订阅发布的MQTT(Message Queuing Telemetry Transport)协议,以及用于控制消息通讯的 面向服务 的 SOME/IP(Scalable Service-Oriented Middleware over IP)协议等。 面向服务的架构可以将使用AUTOSAR Classic的功能ECU以及使用AUTOSAR Adaptive或其他智能操作系统的域控制器桥接起来,通过SOME/IP协议进行控制消息通讯。 面向服务的SOME/IP协议 SOME/IP协议于2011年由当时在BMW集团的Lars Völker设计,并于2013年纳入AUTOSAR 4.

赋能车载数据服务器 - S32G域控制器芯片

近几天的CES 2020上,NXP公司发布了新一代的S32G车载网络处理器。作为NXP S32系列最新的处理器,S32G将汽车行业整车EE架构往高性能,分域架构的现代设计落地进一步推进。 根据ABI研究的报告,目前路上跑着超过4千万的网联汽车,车辆每小时可以产生超4G的车辆数据。基于大规模的车辆数据服务可以为整车厂和车主带来新的机会和体验。大规模的车辆原始数据全量传输到云端处理在延时和带宽方面不能满足应用场景的要求, 数据驱动的车载服务对车载数据处理能力提出了更高的要求 。 随着整车架构朝着分域控制,跨域融合的方向改进,新的EE架构采用的面向服务的网关预计需要10倍于当前车载网关微控制器的性能。除了算力的提升,新的架构也对车载网络,功能安全,信息安全等方面也提出了更高要求。 互联网+汽车的思想自上而下在沉淀和优化 互联网+汽车的思想最初源于造车新势力研发的整车产品,近几年来逐渐在全行业中扩散。 特斯拉及4,5年前国内涌现的造车新势力热潮,经过若干年的实战,一些宝贵经验正在行业链条中沉淀下来。 新型的一级供应商的产生为整车厂提供互联网+的智能化零部件使得整车产品的设计得以更进一步的优化,而部分传统车企也纷纷与各大互联网企业建立合作成立智能网联公司。在这场互联网+汽车的演化活动中,芯片厂商的入场更是将互联网+的优化思想推向了极致,使得上层产品得以更大的简化整体设计的同时提供更强大的产品功能。 以OTA为例,为什么当前整车OTA是一件比手机OTA复杂度高非常多并且容易出错的事情?在传统汽车EE架构中存在着数十到上百数量的功能ECU,这些功能ECU由不同的供应商提供,不存在统一的中央代码仓库,其中运行着各种不同的操作系统及应用软件,以至于整车代码行数规模达到上亿级。过去分散的功能架构使得汽车不像现代手机一样有中央大脑处理器集中处理软件逻辑。 在分散的EE架构中做整车OTA,就好比把30个人的脚绑在一起大家同时往前迈一步一样,这个协调难度比起只有2~3个人做这件事情困难很多 。现代EE架构的设计致力于将软件逻辑集中处理,不断的减少整车的ECU数量降低复杂度及成本。车规芯片处理能力的发展使得软件逻辑得以集中,数据更好的共享。 从中央网关到车载数据服务器 数据作为服务(Data-As-A-Service),网关控制器的芯片处理能力的增强以及其连接车辆数据的中央地位使得其天然适合作为一个车载数据服务器。在分域架构的整车设计里,不同的域控制器向网关注册服务,发现服务及使用服务。域控制器和面向服务网关构成了整车内部的一个分布式系统。拥有数据及算力的车载数据服务器不再是简单的路由转发报文角色,一方面可为整车提供公共的数据存储和共享服务,另一个方面可根据需要对数据加工处理产生新的数据(如跨域融合数据)服务于各个域。原先在云端处理的部分车联网数据业务也可以部署到车载端,为车载HMI及自动驾驶提供实时服务。 过去以信号及控制驱动的设计思想慢慢在转变为以数据及服务驱动的现代整车EE架构设计。 互联网+汽车为车载数据的价值挖掘打开了一扇门,数据分析的目标是产生影响,从原始数据中获取信息学习到知识,达成深刻见解进而领悟出智慧方可最终产生影响。现代整车EE架构使得车辆数据可以被集中处理和挖掘价值,而不再是各路总线上转瞬即逝的一些信号。 NXP S32G 域控制器芯片 S32G芯片的一些关键特性包含: 性能方面:S32G处理器提供了符合ASIL D要求的MCU和MPU处理器,特定应用的网络硬件加速以支持复杂环境下的实时性要求; 信息安全:S32G包含高性能的硬件安全加速以及用于可信密钥管理的PKI支持; 功能安全:S32G提供ASIL D要求的处理器,包含支持同步模式(lock-step)的ARM Cotex-M7微控制器,以及多个ARM Cortex-A53应用处理内核的lock-step clusters功能。 S32G的架构图如上,包含了3对Cortex-M7内核,以同步模式运行。每一对中的两个内核运行着相同的指令,为处理的异常错误检测能力提供了支持,而不同对的内核可以执行不同的任务。另外四个Cortex-A53内核可以配置为同步模式运行(2x2),这样每对内核就可以同时在两个内核上运行任务,或者如果不需要这种处理冗余,四个A53内核也可以配置为独立运行模式。 通讯方面,S32G有20个CAN接口,4个千兆以太网接口和2个PCIe 3.

“互联网造车”的误会:不是让软件工程师去做底盘

前些天有个朋友问我,为什么你们搞互联网的工程师,最近几年,都开始往汽车行业里挤了呢? 虽说之前网上也有过各种说互联网造车不靠谱的文章了,但当这个问题被真实地问到自己的时候我还是蛮惊讶的,当时脑海里第一时间的反应是,一场误会,一场误会。 Tesla是最早被贴上“互联网造车”标签的公司,而国内互联网造车的不靠谱新闻,最早或可追溯至2015年,某汽车startup一场发布会之后,被网友在知乎爆出其demo车是拿Tesla改装的PPT造车事件。此后,互联网背景的老板进入汽车行业便被贴上了“互联网造车”的标签。或许这个标签对于资本市场有着不同的含义,但其实在一个比赛里各个选手无论被外界贴着什么标签,最终的成绩仅与自己和对手的发挥有关。本文尝试从一个技术人员的角度来聊聊开头这个问题。 互联网造车不是让软件工程师去做底盘 专业的事情交给专业的人做,这是一个企业能够壮大发展的一个用人基本原则。汽车行业百年的发展历史,在汽车底盘,动力总成等各个地方已经累计非常丰富的行业经验和人才。被贴着“互联网造车”标签的公司,老板们可都不是傻子呀,自然也不会在这些地方重新发明轮子。一方面,整车架构的团队,往往会聘用拥有多年相关领域从事经验的专家和工程师;另一方面,“互联网造车”公司也会选择与各个零部件供应商合作,共创的方式快速整合行业的优质资源。所以请放心,你花三四十万买到的互联网造车上装的是博世iBooster的制动系统,不是码农纯手工打造的。 整车EE架构的进化产生了大量的软件需求 近几年,汽车EE架构从分散的众多单一功能的ECU,架构逐步集中化,分域控制,跨域融合,最终趋向形成一个或几个中央电脑控制全车IO(传感器和执行器)的架构(参考: 特斯拉智能化路上的左脑与右脑 )。 单一功能的ECU,通常只会包含相对简单的逻辑执行,计算能力和可编程的能力有限。功能ECU各自分离,无法实现多功能协同的智能化,这个阶段的软件人才需求量相对小。而随着域控制器和中央电脑的出现,整车架构算力集中化,传感器数据和执行器被集中连接到若干个电脑,使得大量过去由于单ECU功能限制无法实现的智能化功能得以实现。 举个栗子,当我打开全车窗的时候,可能不再需要空调冷气了,过去空调和车窗各自独立,人们往往需要自行关闭空调,而当有连接着空调和车窗控制器的中央智能模块后,这样一个“打开车窗自动关闭空调”的功能就可以通过编写软件来实现了。这是个简单的协同智能化的例子,而自动驾驶相关的功能可视为更高级的协同智能化。 车上有了电脑之后,谁来在电脑上写软件实现智能化呢?最擅长于做这块事情的无疑是各大院校计算机专业毕业的人才呀,而他们目前就散布在各大互联网高科技企业里。 智能汽车的产业链需要优秀的软件人才 在智能汽车的产业链里,整车厂和零部件供应商的发展是一个相互促进共同创新的过程。整车功能和架构的创新对零部件供应商提出了新的需求,零部件供应商的创新为整车厂带来了新的解决方案。当零部件供应商没跟上整车厂的步伐时,整车厂往往会选择自研。当同一个创新需求有多家整车厂都需要时,满足这样共同需求的创新公司会出现。近几年萌生的自动驾驶和智能网联的startup正是这样的科技公司,区别于传统的零部件供应商,它们也是计算机高科技人才集聚的地方。 曾经有一个同事问我,互联网人进入了汽车行业工作后,是不是将来就业面窄了很多?原本有很多互联网公司可以选择,现在是不是只能在少数几家造车新势力里做选择? 其实不然。一方面,智能汽车行业的发展,对跨界人才的需求只会越来越大,过去我们想去招一个既懂互联网又懂汽车电子的人,只能在美国设研发中心招特斯拉的工程师。而现在,国内蔚来,小鹏等造车新势力经过四五年的实战经验,培养了不少这样的综合型人才。另一方面,计算机原理是相通的(大学课上教的计算机知识可没说只能局限于某个领域),熟悉服务端分布式系统开发的同学,进入车载环境后,会发现车里其实也是一个分布式系统。进入智能汽车行业只是让你的计算机技能应用面更广了,并非换了一个技能。 自主研发不等于什么都自己干 最后,伴随着互联网造车的误会的往往还有自主研发。人们在探讨概念的时候习惯性的会忽略掉一些定语和前置条件。自主研发于整车厂在于研发有竞争力的整车平台架构,以支持更多有竞争力的车型推出。比如通用近期发布的下一代电子架构平台,凯迪拉克CT5将率先搭载。而整车平台上使用的各个零部件是否都需要自研?其实不然,如果市场上有合适的解决方案,车厂往往会选择共赢的合作开发,毕竟这是一个商业社会。 End 新建"

从Google Fuchsia理解“天然无root”

"a dream job is not about dreaming, it's all job all work all reality all blood all sweat no tears. i work a lot and i love it.