作者:焉知智车

在【首届焉知智车年会】上,知行科技系统安全总监宋炜瑾以 「安全集成 - 积极应对智能驾驶领域的新挑战」 为主题,介绍了知行科技的自动驾驶前装方案,分享了开发过程中的一些心得和体验,特别是满足开发效率及安全需求的系统集成。
图片
专攻自动驾驶前装
宋炜瑾首先介绍了知行科技的基本情况,公司是一家专注于提供自动驾驶领域前装方案的系统供应商,愿景是希望成为中国汽车制造商最信赖的一个智能驾驶合作伙伴。
公司的业务方向主要是两部分,一个是产品开发,即自动驾驶的量产产品,主要是智能前置摄像头,以及自动驾驶的域控制器。另一个是提供系统解决方案的合作开发服务,为主机厂以及一些合作伙伴提供对应 L1 到 L4 自动驾驶的工程方案和功能安全服务。
据介绍,知行科技成立于 2016 年年底,2018 年与知名视觉算法供应商 Mobileye 达成战略合作,目前的产品当中所使用的视觉感知芯片来自于 Mobileye。同年,知行科技赢得了 L2 第一个量产项目,7 月份,有了自己的制造工厂;2018 年 9 月与 TUV 南德达成战略合作。
2019 年 3 月,获取了 L4 物流车项目;2020 年第三季度,开始提供 L2 量产产品。2020 年 9 月,再获新的 L2 量产项目,这两个项目之间的区别是,第一个项目采用第一代平台,第二个项目是第二代平台,第二代平台提升在于应对新法规的横穿马路识别要求。目前,知行科技主推的方案是 100 度前摄像头。另一个值得一提的项目是 L2++ 项目,第三季度即将量产,这是一个业界关注的 800 万像素的项目。
宋炜瑾介绍说,目前知行科技研发加生产大约有 200 人,总部和生产制造都在苏州,在常熟有一个测试基地,包括法规测试和模拟测试。公司在德国还有一个研发中心,主要致力于一些前沿研究,比如行人行为预测、交通流量分析等等。
知行的主要客户,现在主要有五菱、吉利等车企。目前运行的项目包括 L2++ 自动驾驶解决方案、L3 自动驾驶方案,以及 L2 级自动驾驶产品。
系统解决方案面向前装量产
宋炜瑾表示,根据实施的项目和既定路线,知行科技目前有两个系列产品,一个系列产品是前置摄像头,有几代规划。第一代已经量产,是 FOV 为 52 度的 IFC;目前主推的是 2.0 平台,170 万像素,FOV100 度,主要是满足法规要求。
还有一个比较特别的解决方案,根据客户要求把额外的 DVR 镜头和的镜头做在一个盒子里提供客户。IFC 3.0 目前还在规划中,是 120 度的水平视角。
关于域控制器相关产品,第一代域控制器只是一个摄像头和控制部分分离的设计,第二代、第三代域控制器设计当中集成了不同的摄像头,以及不同的毫米波雷达,以满足相应的 WA 和 NOP 方案。第四代还在规划当中,将用于高度自动驾驶,也可以考虑搭载激光雷达等传感器。
上面谈到的两个产品系列有大致三种配置方案,第一种配置是 L2 产品系统方案,是高速公路方案。第二种配置是在第一种配置中加入相应的角雷达,以实现变道控制。最后一种配置是 NOP 系统方案,包含相应的摄像头,以及前向雷达,还有高精地图等对应的感知及驾驶员监控系统。

宋炜瑾指出,三个系列方案看起来越来越复杂,同时也带来了新的问题,整个系统遇到的风险也越来越多。首先是功能安全,原来可能只考虑失效,或者是可预见的人为误操作。但是,自从智能驾驶功能发展以后,就需要去考虑由于要用系统替代人去做一部分决定,整个系统本身的局限性,或者是系统设计的缺陷,就会导致整个车辆遇到一定的风险。
另一方面,现在整车厂会考虑使用高精地图以及场端设备,包括相应的软件,这会导致另一个问题:网络攻击。也就是说,现在的系统除了原先要考虑的功能安全方面的因素,还需要考虑网络安全、预期功能安全等其他因素,相对来说,系统解决方案所面临的要求和挑战也越来越多。
法规是功能开发的根本
宋炜瑾说,针对安全方面的要求,目前已经有一些相对应的法规,产品开发也是根据法规来进行。因为无论如何,法规都是基本,没有这些基本,凭空想象去开发产品,就是空中楼阁。

目前来看,网络安全法规有 ISO21434 标准,功能安全有 ISO26262 标准,同时还有对标的 GB/T34590,以及预期安全 ISO21448 这样的标准;同时还要考虑的一点是经常说的前沿水平(State of the art)所能达到的水平,这都要从技术的发展角度去慢慢配合。
要考虑网络安全、功能安全、预期安全,几个法规是目前开发的重要指导。

第一,有很多的法规要遵守;第二,这些法规的实施要求也是一个挑战。例如,功能安全 ISO26262 大家都很了解,但这个法规发布的比较早,2011 年发布了第一版,2018 年的时候 ISO26262 发布了第二版,2017 年的时候 GB/T 34590 发布了第一版,目前 GB/T34590 第二版正在筹划当中,基本上小组意见已经汇总完毕,可能就在今年或是明年发布。同时,ISO26262 第三版也已经在筹备当中,一版接着一版的法规不断更新,提出了更多新的要求。

也许有人会说,功能安全其实不是一个强制性的标准,经常是一个推荐性标准,为什么这么重视它?
第一是这个标准对整个智能驾驶行业的意义,因为这个行业非常重视安全性;
第二,目前有几个强制标准,如 GB 标准,比如制动和转向,都会在附录内提及功能安全方面的要求,这就导致开发的产品需要满足强制性要求;
第三,关于预期功能安全,整个标准的研究应该是从 2019 年或更早就开始了,目前来说,2021 年尚未有正式版本发布。
最后一点是信息安全或者是网络安全,这对很多公司来说是一个比较新的话题,而且大多数公司没有太成熟的经验来应对,但是法规上并没有给你缓冲的空间,目前,ISO21434 的 DIS 版本去年已经发布,而 FDIS 理论上在今年第一季度发布,但现在有延迟。同时还面临一个新的情况,在 WP.29 里规定,欧盟要求 2022 年所有上市新车都要满足网络安全。如果现在的客户中有国外客户的话,也需要考虑将这方面的法规纳入实际的产品开发当中。

从开发管理流程和架构职责入手
ISO26262、ISO21434 等法规其实不只是一个测试、设计标准,而是从整个管理到开发、设计、验证、售后等整个生命周期都提出的要求,所以其中包含大量的内容。那么,这些内容以及这么紧迫的实施节点,一些不是很大的公司怎么应对挑战呢?
宋炜瑾表示,通过对法规非常详细的分析,对其对应标准和流程进行了梳理和合并,知行科技将所有功能安全管理和网络安全管理都合并在了项目管理中。在整个开发过程中只做一次相关项定义,包含所有这三方面的考虑,接下来做危害分析,考虑功能安全和预期安全,做网络安全攻击的威胁分析。
在这个基础上,形成对应的功能安全概念和网络安全概念,形成系统设计的指导以及软硬件开发的设计指导。在这个情况下,从软硬件的相应测试到系统环节考虑安全以及网络安全的综合性的测试,最后分别进行安全确认以及网络安全确认。在这个过程中,除了对这些标准的考虑以及流程的开发以外,知行科技还计划在今年 6 月份,拿到 ASPICE L2 的认证。

她说,以上是流程上的合并,体量比较小的公司也有一个优势,船小好掉头。知行科技在部门职责上也做了划分,所有功能安全建设,包括预期功能建设,以及信息网络安全建设都是落实在系统部门,负责规则的制订,以有效把控流程要求,提升相关实施效率。审核部分都是独立的,以满足合规的独立性要求。

在功能安全与预期功能安全的危害分析方面,以前是做功能安全 HARA 分析设计,后来发现,实际上许多内容都可以进行一定程度的复用,这样就大大减轻了整个分析的负担。
在开发过程中会遇到客户需求有变更的情况,例如 ACC Stop&Go 功能,原来的定义一直是车辆跟停后等待 3 秒时间,这样可以很好地保证在等待过程中没有行人横穿,但现在客户觉得这个体验不是太好,因为 3 秒等待完了之后功能会直接退出,要求驾驶员接管,客户说这个等待时间可不可以变成 30 秒?这时,就会出现一个新的场景,在等待期间,可能会有人从车和车之间横穿过去,这个时候,就需要进行对应的功能安全和预期功能安全分析。把对应的场景罗列出来,而后选择了比较苛刻的场景,即这个人是贴着车直接去横穿过去。在这个情况下,如果车发生了误启动,这时,对应这个场景,严重度和控制度的最后判定结果,是大于 0 的,这就是预期功能相关的一个场景。当然,这个分析的暴露度比较低,所以可以认为是功能安全相关的。

接下来,既然知道它是预期安全、功能安全相关的,就可以做进一步分析。通常,都会采用故障树分析方法进行分析。需要分析车辆误启动的原因是什么?目标没有检测到的原因是什么?从预期安全角度来说,系统受限制的一个原因可能是有盲区,这个时候就要分析盲区的问题。通过对不同安装高度、位置,以及走过行人的分类,在 1.2 到 1.8 米安装摄像头对成人适用,但是小孩仍存在一定程度的盲区。这时,为了尽量减少盲区或是将伤害降到比较低的程度,会对这些安装位置以及上、下视野分配,以及第一可视点提出一些要求,以规避这些预期功能安全的风险。因为预期功能安全不完全通过改进设计来规避的,也有对危害场景的阐明,以尽量减小有危害的未知区域范围。

以上场景不是功能安全相关,如果是功能安全相关,就要从系统的失效方面去考虑,例如可能是摄像头出现故障,这时需要开发内部的安全机制,以控制和消除相应的风险。
网络安全可能存在相应的威胁,比如仿冒、篡改等,这些都会影响相关安全性、完整性、授权、机密性等,需要进行一些 TARA 分析,分析严重程度,所需采取的规避措施。首先是厘清整个系统架构,甚至包括网络节点,比如下载软件、通过其他车身 ECU 进行配置、诊断等。从需要满足的功能和服务方面检查可能的攻击路径,如 OBD 接口被攻击的可能性,或者是 OTA 软件更新造成的数据污染。

在上述情况下,需要考虑如何控制和规避污染,如何去保护。其中一种污染情况可能是数据完整性丢失,这与功能安全考虑的数据完整性丢失的情况重合,就可以用一个机制去保护它。比如用端对端保护来防止出现通信完整性丢失的问题,这样就避免了重复做一些冗余设计。把所有的设计、分析都整合在一起,然后在系统中形成一个策略,传递给软件和硬件。

宋炜瑾最后强调,无论技术如何发展,安全始终是第一优先级的。