随着汽车智能化日趋深入，手机与汽车不断结合，越来越多车企的商业场景中引入了数字钥匙方案，为消费者带来了更加智能和安全的使用体验。
但数字钥匙系统建设之路并非坦途。一个完整的数字钥匙系统涉及车厂、手机厂、芯片厂、软件服务厂商等多个领域，即便在数字钥匙渗透率日益高涨的当下，车企仍然面临着众多的选择和挑战。数字钥匙个头虽小，做起来却并不轻松，这一点做过数字钥匙的工程师们都能深深理解。创新应用须经千锤百炼自不必说，频繁踩坑更是家常便饭。那么今天我们就来谈一谈要“提升用户体验，增加用户粘性”，应该如何有效地做减法，从而优雅地避开潜在的风险，让数字钥匙系统的建设和部署工作能够事半功倍地有序进行。
在数字钥匙系统设计之初，令广大车企最头疼的一个事情便是如何选择数字钥匙协议。回顾数字钥匙的发展历史，自有协议似乎是数字钥匙建设之初的必经之路。在2020年之前几乎所有车企应用的数字钥匙都采用车企或方案商提供的自有协议，车企按自身需求和理解定义通信和认证协议，这样可以保障自由度，但同时也提高了与不同手机对接的复杂度。于是以互联互通为目的的标准数字钥匙协议纷纷登场，像国际上赫赫有名的CCC，国内华为推动的ICCE、以及ICCOA等等。他们通过手机的原生支持，为终端用户提供更好的使用体验。但随之而来的问题是，目前所有的标准协议都还处在发展过程中，数据结构、认证流程等各不相同，并且仍在不断地迭代更新，还没有一个协议可以覆盖市场上所有手机。CCC和ICCE为了提供更安全的数字钥匙运行环境，需要使用手机内置安全元件SE，而市场上内置SE的智能手机还不到50%，这意味着一多半的手机无法部署标准CCC或ICCE；而基于TEE技术的ICCOA支持的手机品牌同样有限。为了兼容更多的手机，车企不得不在车端和云端部署对多个协议的支持，既耗费了研发资源，也增加了开发和运维的复杂度。促成数字钥匙低成本快速落地，就要用尽量少的协议去兼容更多的手机，并保持后续更新扩展的能力。
以我们多年数字钥匙商用部署的经验来看，比较推荐的方式是先使用一套自有协议覆盖绝大多数手机品牌，然后根据自身客户群体分布，选择主打的合作品牌手机所支持的标准协议。毕竟标准协议虽然能提供原生的优质支持，但只能覆盖有限的机型，即便是同一种协议，比如CCC，也需要与不同的手机厂分别进行对接，所以最好是集中优势兵力与主力合作品牌打响发布，随后迭代优化再逐步对接其他品牌。而保留自有协议，可以在尚未与更多品牌手机对接的时候以最低成本的部署做到最大的兼容。比如通过基于软件白盒技术的SDK为手机部署软件安全运行环境并整合到车主APP中，用户安装APP即可放心使用数字钥匙服务，无需与每一家手机厂商单独对接。
从车企的角度，无论使用哪种协议，都请不要忘了建设的初心——提升用户体验，增加用户粘性。所以无论采用哪种数字钥匙协议，使用哪款手机，都应该为用户提供统一的优质体验。这需要在数字钥匙系统的设计之初，就让各个协议可以兼容运行，甚至互联互通，协议A的手机也可以分享给协议B的手机，让用户安心自由地享受数字钥匙带来的便捷顺畅体验。
协议兼容性之外，数字钥匙系统还需要灵活的更新能力，以便于持续地稳定优化系统、迭代扩展应用，因此在数字钥匙系统架构的设计上需要采用业务系统与底层能力解耦的方式。这里的底层能力指的是可以为数字钥匙系统提供基于不同数字钥匙协议的基础能力，包括协议的解析、指令的生成、数字钥匙处理逻辑、以及相关组件的生命周期管理。手机端SDK和车端SE，这一部分可以由专业的数字钥匙系统提供商来负责，关键要提供这些能力的调用接口API；而车企在基础能力之上去构建自己的数字钥匙业务，去组织、修改以实现业务场景不断完善、迭代、和扩展。这种上层应用业务的重新组合以及迭代并不需要对当前的底层数字钥匙能力去进行改动。换句话说，不需要频繁的需求变更，只需通过轻量级的底层能力接口调用，去更新完善自己的业务。以数字钥匙迁移为例，用户在A手机上开通了一把数字钥匙后，又切换到了B手机，那么通常可以有几种处理方式：1）将这把数字钥匙开通到B手机上，同时删除A手机的钥匙；2）开通B手机上的钥匙，同时保留A手机上的钥匙；抑或是3）删除A手机上钥匙，同时也删除所有A手机分享出去过的钥匙等等。在这些需求下，只要使用了底层能力与业务应用解耦的方式，车企完全可以根据自己当前的需求选择不同的场景服务模式，而无需再下需求变更给供应商去修改整个数字钥匙系统，免去了需求、报价、交付、验收等等一系列操作，可以极大缩减系统的迭代周期。
现在数字钥匙协议以及系统服务的架构已经做好了选择和设计，我们就可以进行开发和测试，并为部署上线做好准备了。但在开发和联调测试过程中，不可避免的会遇到各种各样的问题，因为数字钥匙系统的节点实在太多了。比如我们要开发和测试一个后台数据生成并下载到车端SE的功能，就要面对一条复杂且漫长的路径，首先APP或TSP发起请求，数字钥匙系统服务后台计算出业务指令发送到TSP，再到车端的T box，经过车内CAN总线或Ethernet下载到数字钥匙控制器ECU，经过Agent软件处理再通过SPI接口发送到SE。这条路径上，每一个节点都有可能有漏洞或者是缺陷，而任何一个bug都可能导致整个链路的阻塞。那么比较合理的开发和验证方式，是将这些链路分级，抽丝剥茧般逐层逐级验证尽量少的引入变量，最后再进行系统级别的全链路联调。我们可以用样本数据对本地链路进行功能验证和压力测试，之后进行样本数据的在线测试，通过以后再采用真实的测试数据。这样在一层一层地保障各个模块组建工作正确的前提下，才能确保整个链路的畅通以及用例的顺利执行。反过来当出现问题以后也可以去快速定位，省去逐个节点争论扯皮的时间。当然设计验证各个组件之间链路的样本数据并不简单，这需要大量的经验去生成合理的数据以及测验方法。车企可以寻找质量可靠的合作伙伴，对类似的复杂场景去进行验证性测试设计。
好啦，现在看一看，我们选取了合适的数字钥匙协议并且为之设计了灵活的系统框架，还需要的就是方便灵活的测试环境，这样在后面的联调过程中，无论出现了什么样的难题，我们都可以进行快速的定位分析。这里我们也建议从开发开始，一直到功能上线，始终保持着一套台架测试环境，在这个测试环境上面能够有足够的日志，可以对各个阶段出现的问题进行复现和定位，并方便地验证我们的改善方案。
当然，整个数字钥匙系统服务，涉及到车端、云端、手机端等各个节点的建设，主机厂很难在短时间内去深入研究和熟悉如此众多的组件和因素，并做出最合理有效的选择。所以说与有经验的系统服务商合作，是一条事半功倍的便捷之路。
伙伴*捷德
捷德集团作为一家有着171年发展史的百年老店，始终致力于为广大客户提供可信的连接和安全方案。从2017年开始，捷德中国已为多家车企及合作伙伴提供了数字钥匙服务方案，覆盖车端、云端、手机端等多个功能和安全组件，并商用20余件数字钥匙项目，拥有丰富的经验和可靠的产品，可以为车企的数字钥匙系统建设提供宝贵的建议和端到端产品与服务。
扫一扫关注微信
