车联网项目质量管理实战

978-7-115-61122-2
作者: 李泳
译者:
编辑: 谢晓芳

图书目录:

详情

5本书首先讲述了车联网项目质量思维和质量能力基础架构;然后以一个车联网智能产品案例为切入点,详细介绍了如何分析需求、制订质量计划,以及硬件、固件、平台、Web端和APP端的交付过程;最后讨论了如何对产品进行质量评估。 本书适合测试人员、开发人员、软件质量保证人员阅读。

图书摘要

版权信息

书名:车联网项目质量管理实战

ISBN:978-7-115-61122-2

本书由人民邮电出版社发行数字版。版权所有,侵权必究。

您购买的人民邮电出版社电子书仅供您个人使用,未经授权,不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟,与我们共同保护知识产权。

如果购买者有侵权行为,我们可能对该用户实施包括但不限于关闭该帐号等维权措施,并可能追究法律责任。

编  著 李 泳

责任编辑 谢晓芳

人民邮电出版社出版发行  北京市丰台区成寿寺路11号

邮编 100164  电子邮件 315@ptpress.com.cn

网址 http://www.ptpress.com.cn

读者服务热线:(010)81055410

反盗版热线:(010)81055315

读者服务:

微信扫码关注【异步社区】微信公众号,回复“e61122”获取本书配套资源以及异步社区15天VIP会员卡,近千本电子书免费畅读。

内 容 提 要

本书首先讲述了车联网项目质量思维和质量能力基础架构;然后以一个车联网智能产品案例为切入点,详细介绍了如何分析需求、制订质量计划,以及硬件、固件、平台、Web端和APP端的交付过程;最后讨论了如何对产品进行质量评估。

本书适合测试人员、开发人员、软件质量保证人员阅读。

前  言

编写背景

在移动互联网时代,手机APP开始成为万物互联的智能产品。智能产品通常包括硬件传感器、嵌入式固件、大数据平台、Web端和APP端。从功能上看,硬件传感器负责数据的采集。嵌入式固件通过无线网络对数据进行上报。数据到达网关后,由网关对数据进行解析和路由,然后大数据平台对数据进行分布式存储、计算和挖掘分析,并为上层应用程序提供数据接口。Web端及APP端调用数据接口进行业务处理和信息展示。

整个产品开发过程分为软件开发和硬件开发两部分。硬件开发包括硬件设计、结构设计、外形设计、嵌入式开发、生产制造、质检等方面。软件开发包括平台开发、Web开发、APP开发,涉及架构设计、数据存储、接口定义、用户体验设计等内容。从以上内容可以看出,硬件和软件的结合丰富了应用的场景,同时开发规模、复杂度、场景环境等因素让智能产品的开发方式面临极大的挑战。要想发布一款成功的智能产品,需要软件开发团队与硬件开发团队密切协作,从需求设计开始,就保持软硬件功能高度对齐,并在开发过程中进行持续评审和验证,以确保软件与硬件在功能上匹配对应。这迫切需要一套完整的质量体系来指导和规范质量交付过程。

本书结合一个车联网智能产品案例,展示了如何构建软件与硬件一体化的质量体系。

基于这个质量体系模型,本书详细介绍了智能车载终端硬件、大数据平台、客户端程序的质量管控过程,并围绕这些过程,提供了软件与硬件的测试设计用例和开发脚本,帮助读者从头搭建产品质量体系,发布高质量的智能产品。

学习建议

这是一本写给项目经理、质量管理人员、测试工程师的书。学习本书需要具备一定的质量管理、测试设计实践经验,了解质量评估方面的知识。具体的学习建议如下。

思考如何对当前的产品质量成熟度进行评估。你可以先思考当前工作中产品的发布决策是如何做出的。如果由你负责评估产品发布,你会从哪些方面评估产品的成熟度?

对比和参考。本书是一本针对车联网产品质量体系的参考书,可以应用在类似的物联网产品上。在学习过程中,你也可以参考类似主题的其他资料。通过对比和参考同类资料,你可以更全面地学习和理解知识点,进而加强和巩固所学的内容。

本书内容

本书共13章。

第1章介绍车联网产品的特点、应用场景和面临的质量挑战,讨论车联网产品质量管理纲要。

第2章讨论车联网产品质量能力基础架构的关键元素。

第3章介绍车联网案例项目的需求。

第4章讲述项目质量计划。

第5章讨论硬件的评审和测试设计。

第6章讲述固件的评审和测试设计。

第7章介绍硬件生产质量与质检。

第8章讨论硬件售后质量管理。

第9章介绍平台评审和测试设计。

第10章讲述Web端评审和测试设计。

第11章介绍APP端评审和测试设计。

第12章介绍系统质量评估。

第13章讲述使用质量评估。

本书特色

本书具有如下特色。

全面,提供软件和硬件一体化的质量解决方案,全面覆盖硬件产品、大数据平台、Web端和APP端的质量控制活动。

系统,覆盖组织级质量体系建设,包括团队构建、质量方法、度量分析和知识管理等内容。

实用,结合热门车联网产品,提供硬件、平台、客户端的测试设计,便于用户操作和应用,降低产品发布风险。

本书每章的内容虽有一定的联系,但相互独立,读者可以按照顺序阅读,也可以根据自己的兴趣选择性阅读相关章节。

服务与支持

本书由异步社区出品,社区(https://www.epubit.com)为您提供后续服务。

您还可以扫码二维码, 关注【异步社区】微信公众号,回复“e61122”直接获取,同时可以获得异步社区15天VIP会员卡,近千本电子书免费畅读。

提交勘误信息

作者、译者和编辑尽最大努力来确保书中内容的准确性,但难免会存在疏漏。欢迎您将发现的问题反馈给我们,帮助我们提升图书的质量。

当您发现错误时,请登录异步社区,按书名搜索,进入本书页面,单击“发表勘误”,输入相关信息,单击“提交勘误”按钮即可,如下图所示。本书的作者和编辑会对您提交的相关信息进行审核,确认并接受后,您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。

与我们联系

我们的联系邮箱是contact@epubit.com.cn。

如果您对本书有任何疑问或建议,请您发邮件给我们,并请在邮件标题中注明本书书名,以便我们更高效地做出反馈。

如果您有兴趣出版图书、录制教学视频,或者参与图书翻译、技术审校等工作,可以发邮件给我们;有意出版图书的作者也可以到异步社区投稿(直接访问www.epubit.com/contribute即可)。

如果您所在的学校、培训机构或企业想批量购买本书或异步社区出版的其他图书,也可以发邮件给我们。

如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为,包括对图书全部或部分内容的非授权传播,请您将怀疑有侵权行为的链接通过邮件发送给我们。您的这一举动是对作者权益的保护,也是我们持续为您提供有价值的内容的动力之源。

关于异步社区和异步图书

“异步社区”是人民邮电出版社旗下IT专业图书社区,致力于出版精品IT图书和相关学习产品,为作译者提供优质出版服务。异步社区创办于2015年8月,提供大量精品IT图书和电子书,以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。

“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌,依托于人民邮电出版社的计算机图书出版积累和专业编辑团队,相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、人工智能、测试、前端、网络技术等。

异步社区

微信服务号

第1章 车联网项目质量思维

在5G时代,物联网的重要应用之一就是车联网。车联网也被视为物联网体系中有产业潜力、市场需求明确的领域之一,具有广阔的发展空间。

车联网产业是汽车、电子设备、信息通信、道路交通运输等行业深度融合的新型产业,是信息化与工业化深度融合的重要方向,是全球创新热点和未来发展的制高点。车联网目前从国家标准层面完成了顶层设计,成为大力发展的重要新型基础设施。智能汽车已成为全球汽车产业发展的战略方向,未来汽车产业发展的主要任务就是构建一个完善的智能汽车产业生态体系,并强调要积极推进车载高精度传感器、车规级芯片、智能操作系统、车载智能终端、智能计算平台等产品的研发与产业化。

巨大的市场潜力让车联网成为产业关注的重点对象。OEM(Original Equipment Manufacturer,原始设备制造商)车厂、操作系统提供商、车载智能硬件厂商、TSP(Telematics Service Provider,车载信息服务提供商)、通信运营商、车载方案芯片提供商等企业都融入了产业链之中。

车联网提供的服务覆盖了新能源车监管、智能联网、车队管理、UBI(Usage-Based Insurance,基于使用量而定保费的保险)、V2X(Vehicle To Everything,车辆与万物互联)车路协同等场景需求,并通过对路况、车况和驾驶行为等车辆大数据的采集与分析,在云端绘制了人、车、路的数字画像,为智慧城市、智慧交通、创新保险、汽车金融风控等赋能。

1.1 车联网和OBD接口

汽车的天然属性就是移动。现在汽车已经成为除手机之外的最大的移动消费终端,车联网的愿景就是打造汽车生活生态圈,为传统的汽车插上互联网的翅膀,让人们的汽车生活更加美好。

1.1.1 车联网

车联网是物联网在汽车领域的一个垂直应用场景。它是汽车信息服务、汽车电子、通信技术、信息技术的有机结合,车联网不仅把车与车连接在一起,它还把车与行人、车与路、车与基础设施(信号灯等)、车与网络、车与云连接在一起,并以汽车为载体开展服务,实现人、路、车的有效协调。

在技术上,车联网主要依托移4G/5G无线通信技术、GPS(Global Positioning System,全球定位系统)位置服务、汽车CAN(Controller Area Network,控制器局域网)总线传感器、摄像头、雷达等完成车辆行驶状态与周边环境的采集、数据的传输与处理工作。把数据上传到车云平台之后,进行数据分析和挖掘,为产业链后端广阔的汽车后服务市场提供维修、保养、保险、金融风控、车队管理等服务。

从功能上来说,车联网可以提供以下服务。

位置服务,以导航为主,包括路况查看、出行服务。

安防服务,包括车辆的防盗、事故救援等。

CAN数据服务,包括车况检测,获取故障码、里程油耗信息。

辅助驾驶服务,包括疲劳驾驶预警、盲区预警。

位置与服务和安防服务是车联网的早期应用,通过加装各种GPS定位设备实现。CAN数据服务通过T-BOX(Telematics BOX,车载远程信息处理器)和OBD(On Board Diagnostics,车载诊断)设备实现。对于辅助驾驶服务,需要安装ADAS(Advanced Driver Assistance System,高级司机辅助驾驶系统)终端、DMS(Driver Monitor System,驾驶员检测系统)终端、C-V2X车路协同终端。

另外,车联网还提供智能座舱系统,这是主车厂和车联网提供商打造的前装智能座舱系统,包括车载信息娱乐系统、驾驶信息显示系统、显示终端、车身信息与控制系统等。

1.1.2 OBD接口

智慧感知是车联网终端重要的功能之一。如图1-1所示,OBD接口是汽车对外开放的数据接口。通过这个接口,车联网终端可以感知并采集汽车CAN总线上的各种数据。

图1-1 车辆OBD接口

20世纪90年代初期,SAE(Society of Automotive Engineers,汽车工程师协会)和ISO(International Organization for Standardization,国际标准化组织)发布了一套标准,描述了ECU(Electronic Control Unit,电子控制单元)和诊断扫描工具之间的数字信息交换。所有符合OBD-II标准的车辆都需要使用标准诊断连接器(SAE J1962),并通过标准OBD-II通信协议之一进行通信,OBD-II首次在1994年引入,随后成为所有汽车和轻型卡车要满足的基本要求。

OBD接口最初旨在通过监测主要发动机部件的性能减少尾气排放,要求各汽车制造企业按照OBD-II的标准提供统一的诊断模式。OBD接口是汽车总线系统中唯一对外开放的端口。车辆OBD接口位置一般在仪表盘下方。车辆年检就是通过这个接口进行汽车故障诊断的。OBD接口就像心电图的采集器,车联网终端通过OBD接口可以连接汽车内部的CAN总线,通过持续不断地感知车辆数据(包括故障码)评估车辆状况。

OBD接口提供了一种访问多种类型数据的标准方法。OBD接口能获取以下车辆数据。

实时参数,转速、速度、踏板位置、点火提前角、气流速度、冷却液温度等。

“检查引擎”灯的状态。

排放控制系统状态。

冻结帧,故障事件发生时的参数快照。

DTC(Diagnostic Trouble Code,诊断故障码)。

氧传感器测试结果。

VIN(Vehicle Identification Number,车辆识别码)。

点火循环次数。

开启MIL(Malfunction Indicator Lamp,故障指示灯)后行驶的里程数。

基本的OBD系统由一个ECU组成,如图1-2所示,它获取来自各种传感器的数据,如故障指示灯可为车主提供故障预警。现代车辆可以提供数百个参数,可以通过DLC(Diagnostic Link Connector,诊断链接连接器)读取这些参数。通过将OBD设备与用户的汽车绑定,用户在手机客户端就能实时获得车况指数,实时监控车辆的行驶数据,精准统计行驶里程和油耗,分析驾驶中的急加速和急减速行为,从而改善驾驶习惯,让日常驾驶更安全。

图1-2 OBD系统

1.2 车联网终端产品

随着信息技术的发展,出现了诸如汽车共享、网约车平台、快递物流、车联网保险、远程监控、紧急救援等多元化服务的模式。

按照汽车车载产品的装配环节,车联网产品主要分为前装T-BOX和后装OBD产品两大类。前装T-BOX属于汽车原厂配置,而后装OBD产品主要由汽车经销商、保险公司或电信运营商等后服务供应商提供。不论是前装设备还是后装设备,都用于为了获取数据,为用户提供各种用车服务。

1.2.1 前装T-BOX

前装设备指汽车在出厂时就会安装的设备,典型的前装设备有T-BOX和中控屏。通常前装设备会连接车辆CAN总线,直接读取车辆传感器的数据。

T-Box是汽车上用于控制和跟踪汽车状态的一台嵌入式计算机,通过LTE(Long Term Evolution,长期演进技术)通信模块、GPS模块、CAN总线模块等提供路况、导航、车况信息、中控服务等,如图1-3所示。

图1-3 T-BOX

T-BOX可以实现汽车门、窗、灯、锁、喇叭等远程控制功能,如在夏季和冬季,可以提前通过手机客户端启动车辆的空调,当车辆被盗时,远程关闭发动机。

1.2.2 后装OBD产品

后装设备指汽车在出厂时,由汽车4S店或修理厂加装的设备。典型的后装设备包含OBD设备、胎压监测系统、智能后视镜、行车记录仪等。连接OBD接口的设备分为两种,分别是OBD终端设备以及OBD仪器,如图1-4所示。两种设备在产品形态、可获取的数据维度上均有区别。汽车检测4S店的专用OBD仪器能够读取更多的车辆数据。

图1-4 OBD设备

后装的OBD设备不仅可以获取车辆数据,包括车速、发动机转速、水温、电瓶电压等,还可以通过计算获取一些数据,对驾驶行为(包括超速、急加速、急减速、疲劳驾驶等)进行分析。

1.2.3 后装ADAS、DMS

ADAS通过在车辆上加装的多个摄像头,收集车辆行驶过程中的图像数据。ADAS利用智能算法进行物体的动态识别,对驾驶人员进行危险预警,提高汽车驾驶的安全性和舒适性。

DMS通过实时识别司机的驾驶状态,对当前各种危险驾驶行为以及疲劳驾驶行为进行提醒,降低事故发生的概率。

1.2.4 V2X终端

V2X是新一代车联网无线通信技术,实现了车与人、车与车、车与路、车与物的网络连接和数据交换,如图1-5所示。加装V2X终端后,汽车可以与各种交通基础设施(如信号灯)进行通信,提供盲区预警、交通路口诱导等主动、安全的服务。在城市云计算系统的支持下,我们可以随时了解整个城市的交通流量、拥堵状况,并对所有道路车辆进行路径规划,改善城市交通状态,并大幅度地降低交通事故发生的概率。

图1-5 V2X通信功能

1.3 车联网应用场景

近几年,车联网成为市场的热点,各种涉车的场景层出不穷。其中,打车应用更热门。

车联网的应用场景应该是针对车辆构建的商业模式。当车辆联网之后,汽车的运行状态信息都会传到云端,根据这些信息,为车主提供汽车保养、维修、保险、加油等服务。例如,当车辆仪表盘出现了一个故障码后,服务后台人员会收到告警提醒,主动联系车主,为他提供维修保养和安全指导。

本书所提到的车联网商业模式是围绕OBD设备展开的,车辆需要加装一个OBD硬件来获得各种服务。对于车联网厂商来说,有3种商业模式。

销售硬件设备:把OBD设备卖给车联网的下游客户,如企业车队、电信运营商、4S集团、渠道厂商等。在国外,OBD设备的主要使用者是个人车主,车主通常会购买一个蓝牙OBD设备或诊断仪器以协助进行车辆的维修。

收取平台服务费:平台服务通常按年收费,服务费可能包含或者不包含设备价格。一般由车联网运营商为车主提供各种用车、管车等服务,如车队管理等。

数据运营和广告营销:通过对车联网数据的分析,提供某种个性化的服务。目前有巨大潜在市场空间的是车联网保险,如基于用户的里程和驾驶行为为用户提供个性化的保险。

在车联网大数据应用领域,汽车数据的边界就是用户的生活边界,当前车辆数据包括用户信息、车辆基本信息、车辆保养信息、车辆保险信息、车辆行程信息、车辆状况信息。从内容上看,当前车辆数据大致可分为以下3类。

车身基础状况数据和故障码,可用于实现远程诊断,提高整车性能,降低维修费,为续保、维修保养提供依据。同时可以进行数据挖掘,如用户续保行为分析、车辆维修行为、车辆保养的平均里程数、车型故障排名,为用户用车提供更好的体验。

路的数据(包括交通、路况信息、停车分布、市政建设等),利用这些数据对城市拥堵进行评价,对拥堵成因及解决对策进行研究,为公众出行提供建议。比如,从车内空调和雨刮器数据可以得到天气信息等,统计事故发生的时段,如8~9点、12~13点、17~19点等。当用户驾驶车辆时,可以按照车辆的速度推送场景化的音乐,高速时提供激情澎湃的乐曲,拥堵时提供舒缓音乐。

人的数据(包括车主驾驶行为数据、事故车主人群画像),与保险公司出险数据结合,可用于有效地识别欺诈,进行赔付风险管控,如车辆事故后,调取车辆轨迹并进行数据分析,以此作为调查举证的依据。

车联网是汽车消费的入口,车主通常不会主动为多出来的硬件成本和联网资费买单,需要与保险公司、4S店、运营商等机构分摊多出来的成本。车主通过贡献他的个人信息和车况信息使用车联网服务。只有增加车联网用户数,车联网才能产生价值。而要增加用户数,需要整合保险公司、4S店、内容商、网络运营商等。按照业务特征模式,汽车后服务市场中的车联网商业模式分为车队管理、汽车金融风控、汽车后服务、UBI与道路和事故救援服务。

1.3.1 车队管理

车队管理系统可以帮助企业解决车辆管理难、司机管理难、运营成本高等难题,真正实现管人、管车、管成本的目的,让企业管理人员随时、随地快速管理车队,了解车辆的分布和使用情况。车队管理系统的核心功能包括车辆智慧感知(实时仪表盘、车辆跟踪、行车轨迹分段),车辆预警及关怀(碰撞、低电压、拖吊、电子栅栏、离线、故障、年检、保险及保养等提醒)。

1.3.2 汽车金融风控

汽车金融风控主要用于贷款汽车的风控管理。在汽车金融业务中,由金融公司先将贷款汽车发放到各4S店并销售,待汽车销售完成之后,各4S店再将款项还给汽车金融公司。目前,4S店汽车销售普遍采用这样的模式,这种模式的弊端是4S店在车辆销售之后不主动及时结款,同时汽车金融公司也不知道具体的4S店的销售状态和进度,因此推出了汽车金融风控系统。当汽车金融公司将贷款车辆下放到4S店时,将在车辆上安装OBD设备。汽车金融公司通过OBD电子围栏使车辆只能在指定的区域移动,防止4S店之间互相串货。通过OBD设备的拔插状态、行驶轨迹等判断该车辆是否已经销售给最终用户,然后汽车金融公司主动发起催款,解决4S店车辆销售后不及时回款的问题。

1.3.3 汽车后服务

在新车销售时,把OBD设备作为随车销售的大礼包进行准前装安装。基于OBD的车联网系统为4S店构建一套覆盖售中、售后的客户服务体系,4S店可以根据车辆里程、车况等信息进行客户关怀,为车主提供保养、维修、汽车用品等方面的服务。同时,基于车辆大数据分析,帮助汽车主机厂搜集车辆的反馈,分析出驾驶者对汽车性能的潜在要求。

1.3.4 UBI

目前车险现状是,大约87.5%的优良车主在为12.5%的劣质客户买单。在国内,车险公司对客户的风险识别能力较弱,不知道客户的出行状况、职业特征,更不知道哪些是好客户,哪些是风险客户。另外,车险定价模式先天有缺陷,当前主要按照从车因子收取保费,影响保费最大的因素是新车购置价,而从人因子几乎不存在。指定驾驶员基本上已经成为打折因子。据相关部门数据统计,80%以上的交通堵塞、交通事故是由不良驾驶行为(如超速、乱变道、乱插队、不打转向灯、疲劳驾驶、不系安全带、不按导向车道行驶、快车道低速行驶等)导致的。

车联网技术的应用成为推动传统车险向UBI发展的主要推动力,保险公司推出UBI,UBI可以理解为基于驾驶行为的车险定价。UBI的理论基础是驾驶习惯良好的驾驶员应获得保费优惠,保费取决于对实际驾驶时间、具体驾驶方式等指标的综合考量。同时,当车辆发生事故时,车载设备记录下的事故速度以及相关信息会使得理赔评估和处理更有效率。通过一台插入车辆OBD接口的设备,车载设备可以在车主开车时直接监测其驾驶行为,包括行驶的里程数、一天的驾驶时段、行驶区域、急加速、急减速、急转弯等,如图1-6所示。保险公司对这些数据进行分析,并按照评估结果收取对应的保费。例如,跑长途的驾驶者的保费会比跑短程的驾驶者的保费高。在不能拒绝劣质客户的情况下,保险公司可以识别出他们,然后大幅提高保费,同时降低优质客户的保费。目前,国外一些保险公司(如美国的车险提供商Progressive与Allstate公司等)使用了UBI。

对于保险公司,通过OBD设备获取的高质量数据实现精准的风险预判、定价以及理赔和欺诈的预防。保险公司也可以由此推出一些新的产品和业务形态,如里程保险、车辆轮胎险、新形态的盗抢险、基于用户行为的意外险、健康险等保险产品。通过综合地区和城市数据、驾驶习惯和出行习惯数据、位置数据、出险记录数据,并结合温度、雨雪、雷电等天气情况,为用户动态设计一些新的保险产品能够帮助保险公司发掘新的业务场景,提供更好的用户服务。

图1-6 UBI模式

UBI的推广不仅可以为保险公司带来更多的利润,还可以引导驾驶人形成良好的驾驶习惯。

1.3.5 道路和事故救援服务

随着人们出行频率的增加,紧急车辆故障或事故出现的概率也增加了,道路和事故救援就显得很重要。道路救援指汽车道路紧急救援,主要帮助车主抢修故障车辆,提供诸如紧急拖车、吊车清障、现场维修、电瓶充电、更换轮胎等服务。事故救援指交通事故道路救援,包括伤员救治、道路疏导等。在车辆上加装OBD终端,当车辆发生碰撞后,设备会将数据上传到救援中心,车云平台对数据进行分析,主动发起救援服务并与司机确认具体情况,同时出险的用户可以通过客户端APP了解救援的进展状态,并对救援的过程和结果进行评价,如图1-7所示。

图1-7 车联网事故救援

1.4 车联网功能架构

OBD模式的车联网系统主要由OBD设备、车云平台、Web管理服务、APP服务模块组成,在逻辑上是一个典型的物联网系统,由数据采集、数据分析、数据展现等模块组成。对应的技术架构为“管-云-端”三层架构,功能架构如图1-8所示。

图1-8 车联网功能架构

1.4.1 管的功能

车联网架构中的“管”表示通过具有无线通信功能的车载终端,实现车辆与云平台之间的信息交互(见图1-9)。利用蜂窝网络等通信技术,“管”层可实现车与车、车与路、车与平台、车与人等的全方位连接和信息交互。

管是汽车的入口,对应的产品是智能OBD终端,通过OBD终端,实现汽车智能感知。采集的主要数据有OBD数据、GPS数据、G-Sensor数据。OBD数据是最主要的,通过轮询汽车总线采集CAN线上的动态信息(如仪表盘信息、位置信息、故障信息、环境温度等信息),感知行车状态与环境。“管”层面的关键技术包括4G/5G车载蜂窝通信技术、汽车的智慧感知能力。

图1-9 车联网管的功能

1.4.2 云的功能

车云平台是车辆综合信息和服务中心,包括设备连接、车辆监控、数据服务等模块,如图1-10所示。设备连接模块是平台的入口,其功能是对接入的设备进行管理,对数据进行解析和转发。数据服务模块负责对解析的数据进行存储、计算、建模,进而为车辆业务管理模块提供车辆位置、状态、行为等接口服务,同时提供第三方的业务融合能力。

图1-10 车云平台

1.4.3 端的功能

端是指用户信息展示和交互的业务端。这是用户的入口,分为Web端和APP端两部分。业务端的功能是为车主提高各种用车服务,如车辆监控/位置服务、安全服务、里程油耗/车务路线、数据报表服务等,如图1-11所示。

图1-11 车联网业务端的功能

1.5 车联网质量管理挑战

当产品开发从移动互联网转入车联网之后,产品开发内容、形态、应用环境、使用场景等都发生了变化,这使企业在质量管理方面面临着严峻的挑战和考验。车质网曾经对车联网APP投诉做过统计,具体如图1-12所示。投诉最多的问题是功能无法使用,其他问题大多也和功能有关系。

图1-12 车联网APP常见问题

从功能架构上看,车联网和移动互联网似乎没有明显的区别。在终端层面,车联网使用车机终端接入,移动互联网使用手机终端接入。手机的操作系统对硬件的差异和能力进行了封装,为用户提供了统一的、标准的数据访问和展示界面,而车机则不同,需要按照特定的协议和平台通信,其中包括行业标准协议、企业私有协议、行业扩展协议等。这需要在平台侧进行额外的设备管理,进行相应的兼容适配测试。

从使用环境上看,车机是安装在车辆上的,手机是随身携带的,两者的使用环境不同。相对来说,车机的使用环境更加恶劣,受到温度、天气、地理位置、信号强度、路况等的影响。

下面从产品交付的角度介绍车联网质量管理所面临的挑战。

1.5.1 开发模式挑战

互联网的开发内容通常是纯软件的实现,几乎不涉及硬件的设计和开发,而车联网产品是带硬件终端的,因此硬件开发成了车联网中一个很重要的组成部分。通常车联网的服务供应商通过自研或者采购第三方硬件开发硬件。不论采用哪种方式,都无法绕过硬件带来的影响。图1-13展示了车联网产品的开发流程,车联网硬件开发额外的工作内容如图1-13中的虚线框所示。

图1-13 车联网产品的开发流程

快速发布与快速反馈是互联网的主要特点。在互联网纯软件的开发模式下,通过快速迭代,每周快速上线发布版,进行新功能的推广和试错。但车联网涉及硬件开发和软件开发两部分内容,这就要求在开发之前进行详细的市场调研和项目评审。在功能需求和产品设计明确后,才能够开始动手,否则会造成很多意想不到的问题。比如,硬件方案不支持软件展示的功能,软件需求变动需要修改硬件设计或元器件的选型,此类问题一旦发生,就会对产品团队产生巨大的影响。

车联网产品的软件团队和硬件团队是一个整体,需要进行大规模的协作。在这个过程中,需要使用详细的文档传递需求。在设计之前,进行严格的需求评审和设计评审。在研发过程中,软件团队和硬件团队要定期沟通,要严格控制需求变更,杜绝功能的变化导致对硬件进行反复修改。

车联网中相关硬件成本的投入和软件团队与硬件团队合作的问题目前很难单纯通过敏捷开发模式解决。

1.5.2 产品需求挑战

因为车联网产品涉及硬件,所以开发人员需要对需求进行严格的评审和变更控制。一旦确定设计方案,就要冻结需求。如果需求不明确,就会造成硬件成本的浪费、开发周期的失控。

追求功能完美是个巨大的陷阱,功能不是越多越好,尤其是做智能硬件开发,在进行产品定义时,不能想象得太完美。一旦超出自己的能力边界,时间和成本就会失控,因此首先需要定义一个具体的应用场景,满足客户的最小功能集合。

某公司曾经开发了市场上第一款4G车载设备终端,它带Wi-Fi功能,能够支持5~6人的热点连接。当时,这个产品是移动办公的天然载体,但没有注意的是,引入的Wi-Fi热点功能影响了流量管理。在初期使用时发现流量经常提前耗光,这导致车机的数据无法上报,遭到客户的投诉。这不仅需要额外开发流量监控、流量充值等功能,还要支持Wi-Fi密码和名称的修改等功能。从客户的使用场景上看,该设备终端一般用于公务车管理,没有热点的诉求管理,在设备上增加一个Wi-Fi模块,一方面增加了成本、降低了产品的竞争力,另一方面提高了管理开销,得不偿失。这对后续的开发也是一个教训,在随后的新产品上,Wi-Fi作为一个选项,由客户选配。

1.5.3 产品设计挑战

本节介绍产品设计可能面临的挑战。

1.硬件外观设计

硬件产品的工业设计一般通过委外进行。在和第三方设计机构沟通之前,团队内部需要明确思路,知道自己想要的产品是什么样的。团队对产品的卖点和使用场景及限制因素等有充分的考虑,能够在外形、材质、成本、工艺等方面进行综合评估和决策。同时,团队要和委托的设计师提前进行沟通,谨防承诺结果和设计结果有较大偏差。

2.硬件结构设计

在设计硬件结构时要优先考虑性能因素。针对车载终端设备,射频、散热、GPS定位信号、LTE通信信号、Wi-Fi信号是关键的性能因素,在设计时需要重点规划。尤其是在车载环境下,因为车辆处于高速移动状态,所以对位置信息具有更加精确的要求。在高速移动状态下,对通信信号和定位信号也提出了较高的要求。

每辆车的OBD接口的位置有差异,在设计时尽可能使天线面朝车外,以增强信号的接收面积。同时,在安装上要考虑便利性和成本。有时为了节省成本会将主机和外接的天线设计为一体机,在遇到特殊的车辆时会无法走线。

另外,结构设计需要精准,单位要统一,开发板设计后要进行硬件和外壳组装验证。即使2mm的差别也会导致外壳无法紧密结合。

3.硬件技术方案选型

通常激进的团队喜欢选择流行的技术和工具,保守的团队喜欢使用成熟的技术和工具。关于硬件技术方案,也存在类似的问题。硬件技术方案选型涉及主芯片方案和支撑的技术栈,相关的开发涉及RTOS、Linux、Android等技术栈。硬件原则上越成熟越好,但每个硬件厂家的主芯片都有生命周期,要注意芯片成熟后期的方案、存在的市场竞争风险和今后产品持续供货的问题。

要选择主流器件,如恩智浦(NXP)的CAN芯片是主机厂的主流方案,已被多家厂商应用,稳定可靠。原则上,不再考虑非主流的新方案,否则会带来较大的风险。同时,硬件的选型要能够支持产品量产的需要,例如,如果设备的关键芯片MCU STM32严重缺货并且价格涨幅较大,则需要考虑国产的GD32的备案,并提前进行验证与确认。

4.产品功能设计

车联网产品在设计上需要考虑硬件、平台和客户端三者功能的对齐。以4G车载终端为例,最初硬件支持Wi-Fi功能,当客户发现流量消耗特别快的时候,提出应该可以在后台关闭该功能,在设计平台时没有考虑到这个需求。为了添加关闭Wi-Fi这个功能,在开发嵌入式软件时增加指令,在网关中添加指令解析,在平台中增加指令接口,在客户端增加操作界面,从下向上对整个系统都进行了修改,这对整个系统都产生了影响,开发人员在功能上重新进行了回归测试,否则会带来系统不稳定的风险。

软件版本发布后,部署的边际成本基本为零,但硬件在大规模量产后需要进行成本控制。若设计之初不考虑整机的成本和物料的通用性,则采购周期会很长,物料成本将会失控。

对于产品包装,不同的客户也需要区别对待。针对2B的客户,进行一般的产品包装即可;针对2C的客户,包装需要精心选择,在外包装上进行美化设计。

1.5.4 供应链挑战

供应链对于互联网来说是一个陌生的领域。元器件采购、生产工艺、贴片排期、组装生产等环节可能都会出问题,没有详细的计划和生产跟线,就无法确保交付的时间和质量。这也导致很多互联网厂商初次进入智能硬件领域之后碰得头破血流。通常在供应链方面,需要解决物料供应、成本控制、代工厂选择和评估等关键问题。

首先,要有可靠的物料供应链渠道资源,它们能够为产品硬件器件选型、样机、试产和量产提供物料上的保障。在软件领域内,找到有软件技能的人员;在硬件领域内,先要找专业的供应链人员,然后联系渠道供应商,为硬件团队提供各种元器件。

其次,需要建立完善的物料采购系统,要有常用物料库和备用料。在价格和供货周期上进行仔细评估,如果硬件方案成型之后物料短缺或周期拉长,则会对整个产品的交付产生致命的影响。另外,受到国际贸易的影响,进口元器件的价格涨幅较大,需要做好国产芯片的替换方案,以应对价格上涨带来的影响。对于同样规格的器件,应有很多不同的供应商。对于相同的供应商,元器件的产地不同可能会导致性能的差异,这一点尤其重要。例如,一个供应商提供的LDR(Low Dropout Regulator,低压差稳压器)的温度有差异,经过几次客户投诉后,研发人员进行元器件的比对和追溯,发现该器件的规格和之前完全一样,但生产的批次和产地不同。

接着,对物料器件的来料检验进行严格把关和控制。在对产品进行大批量生产时,一定要对物料进行来料检验,对送样样品进行比较,对产品进行批量抽查检测,确保量产的元器件和样品是一致的,这样才能尽可能地避免隐患。例如,某方案商提供了一个新的GPS模块方案,模块测试报告中性能正常,样机测试效果还不错。然后,进行小批量生产,并在出租车上进行了两周实车测试,就在决定进行量产下单的时候,观察到测试车辆的轨迹开始出现问题,从第13天开始GPS没有数据了。回收设备后研发人员发现GPS模块没有数据输出,模块原厂的技术工程师进行定位分析后,没有明确的结果,最终放弃了这个GPS模块。

最后,严格控制硬件版本,原则上硬件发布后不再修改版本,否则库房将堆满了样机。

1.5.5 产品测试挑战

本节介绍产品测试时面临的挑战。

1.测试对象和测试技术

互联网程序测试用例的设计在用户场景设计上是针对C端客户进行的,模拟用户的行为并进行操作,所需要的技术栈主要与手机和Web类的开发相关。而车联网则将这个技术范围和测试内容扩大了,测试人员需要测试车载硬件终端,需要了解基本的硬件常识、通信协议和串口命令等,需要使用万用表、示波器和频谱分析仪等工具。遇到车机路测的时候,会开车也成为一项基本技能。

2.测试策略和方法

可以通过自动化测试提高互联网测试的效率,针对APP的适配性可以进行手机真机适配测试,整体的成本是可控的。而车联网产品的使用环境是汽车,要在不同的车型上安装产品,设备的兼容适配性将成为关键,而且必须进行实车的适配测试,这不但成本巨大,而且周期长。汽车的使用环境受到天气、道路状况、安装位置、GPS定位信号等因素影响,可能会产生各种问题,这些问题无法避免,模拟软件只能进行有限条件下的功能验证,需要进行大量实车测试并通过收集数据验证。

3.使用对象和数据访问方式

互联网的使用对象是C端真实客户。用户通常使用手机等客户端程序来浏览信息、提交评论和进行信息互动,大量的操作是读操作,这对数据库的查询性能提出了要求;而车联网需要处理两类数据,一类是来自硬件的车机数据,另一类是来自手机端和Web端的用户数据。其中,车机数据需要按照一定的频率持续不断地提交,这对平台和数据库的性能提出了较高的要求,这也是和传统的互联网有较大不同的地方。

4.缺陷修复成本

互联网公司的本质是商业性的,面对市场的竞争,喜欢追逐热点。互联网产品的特点是快速迭代,版本往往由时间驱动,这导致在最后上线之前没有时间进行细致的系统测试。即使之前没有做过单元测试,也匆忙上线。产品上线后,若出现问题,可以通过升级修复,其根本原因就是2C用户关注的是补贴和优惠,对一般的功能性问题容忍度较高。

同时,对于用户来说,互联网产品的缺陷修复基本是透明的。在热修复技术的支持下,用户几乎注意不到产品缺陷的修复,一切都是自动触发并完成的。

从商业模式来看,车联网主要针对B端客户。C端客户通常是个人用户。这两类用户的质量要求差别很大。B端用户是付费买家,对产品质量的容忍度非常低。一旦产品出现问题,就会造成较大的影响。小问题可能会引起客户投诉,大问题将会导致召回和索赔,并严重影响品牌和信誉。因为硬件是物理存在的,所以如果硬件发生故障,需要通过回收设备修复。这个过程涉及产品召回、工厂返修、验证测试、客户安抚等问题,并会产生巨大的成本。此类质量问题对于任何公司来说都会是一场灾难。

5.测试环境和周期

在代码编写完成后,互联网软件产品就可以直接在本地环境下运行和使用。使用过程中发现的问题可以随时修复和升级。而车联网硬件产品需要进行外观设计、结构设计、电路设计等,PCB(Printed Circuit Board,印制电路板)贴片变为PCBA(Printed Circuit Board Assembly,印制电路板装配)后才能够开始进行软件的调试。整个过程试制成本高,周期长。同时,因为试制的样机数量少,所以无法通过工业流水线生产。

手工样机往往导致设备功能不稳定,在调试和定位上会花费很多时间。产品硬件方案封版后,将导入供应链并进行生产。在量产前还需要进行小批量首件验证,以确保后续大批量生产的质量。首件测试的时间限于1~2天。由于时间短,因此很难进行全面、系统的测试。如果硬件方案在前期没有经过详细的评审和工程样机的系统测试,一旦大批量生产,就会导致批量的问题,这个修复过程基本是不可逆的。

1.6 车联网产品质量管理纲要

车联网产品包括硬件和软件两部分。在功能设计上,车联网产品分为硬件设计、硬件生产、嵌入式软件开发、平台开发、Web端开发和APP开发。车联网产品是一个非常复杂的系统。针对复杂的系统,需要借助方法论模型进行分解。

1.6.1 质量管理思维模型

我们尝试从道、法、术、器与例的维度建立质量管理思维模型,如图1-14所示。

图1-14 质量管理思维模型

道是理念和价值观,映射到质量管理上,就是质量的商业价值观,能够解决客户的哪些问题,具体表现就是组织的质量方针。

法是原则和规章制度,是“道”的实现保障,映射到质量管理上,就是质量体系和规范,具体表现就是质量能力基础架构。

术是方法和经验,是“法”的具体操作,映射到质量管理上,就是质量方法和实践经验,具体表现就是质量计划、评审与测试设计方法。

器是工具和仪器,是“术”的实施支撑,映射到质量管理上,就是各种质量工具和检测仪器,具体表现包括软件持续集成工具和硬件测试仪器等。

例就是应用场景和案例,是“器”的具体应用,映射到质量管理上,就是应用的产品。具体表现就是软件平台、硬件产品。

1.6.2 质量体系模型

基于质量管理思维模型,结合车联网产品的业务特征,建立一个抽象的质量体系架构。体系模型包括组织级质量方针、软硬件质量目标、质量能力基础架构、质量计划、硬件和软件的测试设计、软硬件系统度量、知识管理模块等,具体如图1-15所示。

图1-15 质量体系模型

1.6.3 组织质量方针和目标

1.质量方针

质量方针是指组织的质量管理理念和思想,是在组织内开展质量活动的基本原则,是企业质量行为的指导准则。它表明了组织对质量的承诺和态度,需要在组织内部从上到下贯彻落实、执行。

对于产品来说,部分质量方针描述如下。

全员参与、持续改善,交付有竞争力的产品。

精益求精、持续改善,交付用户满意的产品。

客户至上、持续改善,交付性价比高的产品。

一次性把事情做好,交付让客户满意的产品。

2.质量目标

质量目标是组织为满足市场要求和内部质量持续改进而进行的承诺,是质量方针的体现,也是组织内开展质量活动的指南和方向。在组织内制定质量目标时,首先通过了解组织内存在的问题针对性地制定对应的改进目标。部分问题样例如下。

当下产品存在的问题和缺陷导致客户投诉。

团队协作效率低下,产品生产效率低下。

产品不良率提高,质量修复的成本巨大。

和市场同类产品比较,缺乏竞争力。

其次,产品需要满足国家和行业标准的要求。然后,结合组织自身的产品业务特征,参考领域内同行的实践经验来制定。质量目标必须是具体的、可度量的、可达成的、相关的、有时间限制的。质量目标需要有一定的挑战性,如果能够轻易达成,开发人员就失去了促进持续改进的动力。

基于挑战,结合产品特征和功能模块,对车联网产品的质量目标进行分解,如图1-16所示。

图1-16 质量目标分解

基于质量方针,以交付、有竞争力的产品为目标,对质量目标进行分解。硬件质量目标主要指硬件交付后开箱检验的合格率。

平台质量目标是指平台支持接入的车辆和用户数量,同时平台性能可以根据接入的车辆和用户数量进行扩展。

客户端质量指标是指手机端APP或Web的功能满足最终用户的使用要求。

系统运维质量目标是指产品的服务质量,包括部署和版本升级的活动。

市场售后质量目标指通过各种售后活动解决客户在使用过程中的各种问题。

以上只是部分质量指标,具体可以根据业务的需要进行增加和修改。

1.6.4 质量能力基础架构

产品或项目开发的通用元素包括人、技术、过程、工具。为了有效开展产品质量管理活动,需要尽快搭建一个质量能力基础架构,如图1-17所示。

图1-17 质量能力基础架构

首先,需要构建质量团队,定义团队的职能和职责,识别出质量人员的能力集,并开展招聘和评估。

其次,定义产品质量活动流程,作为团队人员日常沟通和工作的指导原则。

然后,根据产品的特点和团队的能力集,选择合适的开发技术栈和质量管理工具,提高开发效率,降低质量风险。

最后,持续不断地收集测试数据,促进产品的改善。

在这个过程中,需要从时间、资源、成本等方面对产品进行项目管理,并对过程成果进行整理和归档,完成知识的沉淀。同时,加强协调管理来提高团队间的协作效率,并通过风险管控发出预警,降低产品发布后面临的风险。

1.6.5 系统质量计划

车联网产品涉及硬件设计、嵌入式开发、生产制造、平台架构、Web开发、APP开发等方面的内容。质量管理覆盖硬件开发、软件平台开发、供应链采购和生产、售后服务等环节。需要定义系统级的质量计划,从整体上来考虑产品的质量需求,并开展有针对性的评审和测试设计来降低发布风险。

1.质量计划

在制订质量计划时,最关键的是识别产品的质量属性,并建立产品功能、质量属性、质量子属性、测试方法、度量方法的映射关系,以提高质量活动的有效率和覆盖率。

质量是由一系列的特征属性组成的。正如评估一个人的健康情况一样,我们做体检时医生会从外部和内部两方面检查。外部检查也称为显性检查,是外在的、可以观察到的,如耳、鼻、舌、牙的状况等;内部检查包括CT、血压、血检等项目。但这只能从物理上评估身体情况,要完整地评估一个人的健康状况,还需要从隐性部分入手,这就是心理评估。心理状况看不见、摸不着,也无法简单地使用仪器测量,但这是影响个人身体健康的重要因素。因此,要完整地评估一个人的健康状况,需要找出影响健康的各种特征因素。

车联网产品的质量评估也类似,若要全面地评估产品质量,需要提前识别出影响产品质量的各种属性。组织的质量方针和质量目标为质量评估指明了方向。在具体操作中,需要将质量目标转换为具体的质量实施策略,把质量目标转换为具体的质量属性。我们以市场质量目标为例来进行说明,站在客户使用的角度考虑车联网产品的一些需求。部分需求如下。

稳定性。车载设备能够在不同的路况、天气下稳定上报数据,当处于通信信号盲区时,能够自动存储数据并进行事后的上报。

安全性。车载设备安装到车辆上,不会引起车辆故障等。

效率。在功能上保证时效性,主要体现在车辆电瓶电压不足后,用户能够及时收到提醒更换的消息。若使用在金融风控设备上,当设备被拆除后能够第一时间报警。同时,设备可以实时上报车辆的位置、状态、行程等信息,让车主了解自己的驾驶行为、行驶里程和油耗等情况。

智能性。主要体现在数据的算法分析结果对不同用户是可读的、准确的,比如,给车主提供的故障码不应该包含大量专业词汇。通过对故障码的分析,车联网产品能告知车主故障的影响程度,并提供远程的诊断支持。

提取客户需求,归纳为质量特征,在质量指标和质量特征之间建立关联。然后,对质量特征进行细化,在参考ISO/IEC 25010系统和软件质量模型的基础上,为质量特征和质量属性建立映射关系,并对质量属性进行分解,进一步细化质量属性的统计粒度。这就为组织的质量方针和质量指标与质量属性建立了关联,为具体的质量设计提供了方向和指导,如图1-18所示。

图1-18 质量方针-指标-特征-属性映射关系图

按照这种方式,分别针对车联网产品硬件、嵌入式固件、平台、Web端、APP端等模块开展质量属性的设计方法,对研发内部质量、产品系统质量、用户使用质量等方面开展全面的评估。

2.评审与测试设计

在质量体系模型中,测试设计内容主要指硬件测试设计、嵌入式固件测试设计、硬件生产及质检、产品售后质量、平台测试设计、Web测试设计、APP测试设计。

相关的质量活动如下。

评审。这是质量管理的重要手段,尤其是针对前期的产品需求、系统设计和质量计划等内容要进行重点检查和评估,以便在早期发现问题,降低后期的修复成本。车联网产品的评审可以参考业界一些现有的标准。

测试设计。也就是说,为具体的测试活动执行提供操作指南。在设计之前,需要熟悉产品需求规格说明书,并对需求进行评审。同时,需要对市场上同类产品进行分析和调查,了解这类产品的功能说明和操作流程。把这些信息作为测试设计的输入。提取产品需求规格说明书中的功能点作为产品测试检测点,对这些产品需求进行优先级的划分,根据重点的功能识别出产品的质量属性,并应用相关的测试方法开展测试设计。另外,基于产品的使用场景和失效模型完善测试用例。

确认和验证。目的是确认过程或项目的每个工作产品正确地反映了定义的要求。通过执行不同类型的测试用例确认功能、资源效率、稳定性、兼容性等质量属性的满足程度,记录验证活动的结果。

1.6.6 质量度量评估

质量度量评估的目的是度量产品需求满足客户的程度,即度量是否达到产品设计的标准并满足客户真实场景下的使用。车联网产品的质量评估包括软硬系统质量度量、产品使用质量度量两方面,它们分别从系统质量、使用质量两个维度全方位评估产品质量成熟度。

在操作过程中,需要先识别出产品的各种质量属性,明确度量的对象和度量指标,然后通过执行对应的测试用例搜集测试数据,并进行数据分析,参考业内的质量标准——ISO/IEC 25010质量评估模型来对产品开发过程质量和用户使用质量进行系统评估,为发布产品提供参考和依据。如果公司产品质量标准高于市场同类产品的质量,那么产品质量将成为影响市场竞争力的重要因素。

1.7 小结

本章首先介绍了车联网的基本定义,然后介绍了常见的车联网终端产品,并对其商业模式进行了详细描述。结合车联网产品的特点,从开发模式、产品需求、产品设计、供应链、产品测试等方面介绍了车联网产品质量管理所面临的挑战。围绕这些挑战,本章提供了开展车联网产品质量管理的解决方案和质量体系模型。其中,质量体系模型是开展车联网产品质量管理活动的行动地图。从组织内的顶层质量方针入手,对质量目标进行解码,然后搭建质量基础体系架构。在此基础上,制订车联网产品的质量计划,为质量活动的实施提供具体的操作指南。

读者服务:

微信扫码关注【异步社区】微信公众号,回复“e61122”获取本书配套资源以及异步社区15天VIP会员卡,近千本电子书免费畅读。

相关图书

JUnit实战(第3版)
JUnit实战(第3版)
渗透测试技术
渗透测试技术
深入理解软件性能——一种动态视角
深入理解软件性能——一种动态视角
云原生测试实战
云原生测试实战
现代软件测试技术之美
现代软件测试技术之美
Android自动化测试实战:Python+Appium +unittest
Android自动化测试实战:Python+Appium +unittest

相关文章

相关课程