ADAS/AD开发17- 安全角度
前言
智能驾驶从L3级别开始，就要由智能驾驶系统（下文简称“系统”）承担责任了。
因此，“安全”是智能驾驶系统顺利落地、智能驾驶行业顺利发展的无法回避的关键话题。
对于智能驾驶安全，传统的功能安全设计是无法覆盖L3及以上智能驾驶诉求的。因此需要从新的角度审视安全。例如，我国已经开始立法来规范目前火热的汽车智能化的趋势，名字叫做智能网联汽车，强调自动驾驶和车联网两个发展方向。那么智能网联汽车的安全势必要考虑网络安全的因素（联网），以及因自动驾驶分级导致的新的安全需求（接管）。
正文
一、概念介绍
按照SAE的自动驾驶级别划分，如下图，智能驾驶系统在运行过程中会牵涉到驾驶责任（驾驶员/系统）和系统作用域（ODD）的切换。这个切换，可能是成功的，也可能是失败的。切换成功，那是应该的；切换失败，就算是另一种“失效”了，是无法接受的。这样，就牵涉到安全！但是，这个安全跟“功能安全”没有关系，属于新增的需求。
图1 自动驾驶分级
图2 不同等级对驾驶员的要求
罗列自动驾驶概念开发阶段常用的几个概念（DDT/OEDR/ODD/MRC/Fallback/MRC）：
DDT - Dynamic Driving Task 动态驾驶任务，完成车辆驾驶所需的感知、决策和执行，包括但不限于：控制车辆横向运动；控制车辆纵向运动；目标和事件探测与响应；驾驶决策；控制车辆照明及信号装置。
OEDR - DDT包含一项目标和事件探测与响应的子任务，缩写为OEDR，全称是Object and Event Detection and Response。其实就是感知任务。系统可以负责OEDR，当然人也可以负责OEDR，例如一辆没有ADAS功能的车，不一直都是人负责“目标和事件探测与响应”的嘛？
ODD - 设计运行范围，英文全称 Operational Design Domain。设计时确定的驾驶自动化功能的运行条件。
Fallback - 接管，全称Dynamic Driving Task Fallback（即DDT接管）。当车辆超出ODD时，或者DDT相关系统失效时，由人或者智能驾驶系统执行动态驾驶任务接管（即便由系统接管，肯定也不可能维持之前的驾驶状态了。例如，系统本来执行的DDT是HWP，突然系统出问题了，这个时候系统会执行Pull over紧急靠边停车等DDT。Pull over是一种后备DDT，可将车辆和人员的风险降低到最小，即最小风险状态，缩写MRC，英文全称Minimal Risk Coondition）
接管的过程如下图所示：
图3 来自《上海汽车》泛亚汽车技术中心有限公司的毛向阳、尚世亮和崔海峰的文章截图
利用以上概念，对自动驾驶系统进行分析，然后按照以下几个维度进行最终的L0-L5的自动驾驶评级。
持续的纵/横向控制维度 （由系统？还是人类？）
OEDR维度 （系统？人类？）
DDT-Fallback维度（系统？人类？）
ODD维度 （系统？人类？）
还有推荐考虑地理围栏（Geofence）维度来帮助分级的。所谓地理围栏，就是指在一定地理区域内，智能驾驶汽车的各种运行状态都受到电子监控。
个人认为，地理围栏应该属于ODD的深化和细分，限定场景和工况。
图4 纵目科技在智东西上分享的地理围栏分级
图5 汽车电子设计微信公众号上关于地理围栏的说明
二、围绕安全开发的常见安全元素：
按照NHTSA发布的《AUTOMATED DRIVING SYSTEMS 2.0 - A Vision for Safety》自愿性指导书的分类，可以将ADS安全元素分为以下几个维度来考量：
系统安全 System Safety；
设计运行范围 ODD；
目标时间检测及响应 OEDR；
接管 Fallback（MRC）；
网络安全 Cybersecurity；
数据记录 （EDR 车载黑匣子）；
防撞性 Crashworthiness；
碰撞后分析 Post Crash Behavior；
检验方法 Validation and Testing；
人机接口 Human Machine Interface（HMI）；
消费者教育和培训 Consumer Education and Training；
联邦、州和地方法律 Federal, State and Local Laws。
三、智能驾驶常用安全相关的设计方法论（方法的方法）：
功能安全（Functional Safety : ISO 26262）
预期功能安全 （Safety Of The Intended Function - 即SOTIF : ISO/PAS 21448）
网络安全 （Cybersecurity：ISO/SAE CD 21434）
传统的主动安全及被动安全 （ABS/ESP, Occupant Restraint System, etc.）
其中，功能安全主要覆盖电子电器系统故障（系统性故障+硬件随机故障）引起的危害。功能安全默认是人在驾驶，人在主导整个操作过程。一旦系统出现故障，驾驶员默认能够非常称职地参与危害的控制；
预期功能安全主要覆盖电子电器系统非故障引起的危害。例如，1. 车辆运行过程中超出了ODD范围，需要驾驶员接管（但是系统本身并无故障，并不算是“失效”），而且这个接管过程需要一定时间。在这个接管的过渡时间中，要保证系统能够“Hold住”，这就对系统提出了新的安全要求；2. 视觉感知系统将一个救护车误认为是一辆普通的卡车，而导致车辆没有给救护车让道，电子电器系统没有任何失效，但是确实形成了某种危害。一般的SOTIF的验证都是围绕ODD/OEDR/Fallback等这几个关键词引申出来的含义展开的。比如，系统性的把智能驾驶系统暴露出ODD，看看系统接管的性能是否OK；系统性的训练和测试系统的OEDR能力（感知极端工况），看看系统的响应是否正确。
网络安全主要覆盖因车辆联网导致的外部网络恶意对车辆、账户或隐私进行攻击，而引起的危害。例如，可以通过限制系统的诊断者和调试权限来减少被攻击的程度。类似的做法还有：限制诊断权限；任何有权限访问车辆运算平台的密码都需要注意隔离和保护；控制外界访问固件的权限；记录访问历史；控制无线接口等等...
四、智能驾驶系统常用的安全设计手段
1. 系统本身的多样性和系统冗余：
多样性（Diversity）个人感觉主要指感知这块（传感器的种类），比如检测车道线，用了视觉传感器检测（前视摄像头），再来一个激光雷达检测，针对车道线检测这块儿内容，就多样化了起来。毕竟不同的传感器有不同的失效模式，只有组合使用，才能保证感知数据流的万无一失。其实也是另一种形式的“冗余”吧！
系统冗余（Redundancy）主要是为了提高系统可靠性，一般通过将功能部件加倍的方式实现。智能驾驶系统落地的一大拦路虎就是成本高。成本高的其中一项原因就是“冗余”多。在ADAS阶段，人是驾驶的责任方，因此一旦系统搞不定某种驾驶状态，就可以由人来接管。这里面，人其实也是智能驾驶系统里的冗余设计（的一部分）。例如感知层面（OEDR），系统看不到的东西或者误检测的东西，人能分得清，人就会介入；计算层面，系统算的不准，控制的不好，人也可以介入纠正车辆运行状态；执行层面，例如刹车的ESP（电子电气部件）坏了，没了助力，但是人可以硬踹刹车踏板（没了助力而已），让车停下来，转向也是同理。在AD阶段，就需要系统负责了，那么没了人做备份，还能用什么来代替人类作用呢？答案是：再弄一个系统... 也就是冗余系统（或部件）啦。（将冗余进行到底！）
冗余的计算单元。搞两个车规级的计算机（或者同一个计算单元有冗余核心芯片、冗余电源等类似两个独立计算单元的设计）。一个挂了，另一个顶上；
冗余的制动系统。例如典型的博世制动冗余解决方案： ESP + iBooster;
冗余的转向系统。3相、6相、12相电机绕组；双份控制单元...
冗余的定位系统。比如基于信号的定位（GPS或RTK）的绝对定位；基于视觉的道路特征定位；基于Lidar的SLAM定位；基于IMU的定位。或者基于以上各种定位排列组合出的各种组合定位方法等等。
冗余的电源模块。
冗余的AEB系统。除了上面冗余的两个域控制器外，还要再搞一个冗余的、一直在保持工作的节点（控制器，例如智能前视摄像头模块），来独立检测目标并随时准备做紧急制动。假如两个域控制器都挂了，或者视决策算法出现失误，例如，可以让ADAS常见的1R1V方案形成一个小的子系统，独立于大的ADS（自动驾驶系统）之外，做冗余紧急刹车。
冗余的通信架构。比如，两路CAN（CAN主和CAN备份），CAN备份上挂一些关键节点，如ESP、EPS...不要把所有相关节点都挂上去（没必要）。
“冗余”的传感器架构。其实就是上面文章讲过的感知多样性！什么摄像头啊、毫米波雷达啊、激光雷达啊、超声波雷达啊、IMU啊、高精地图啊、甚至V2X啊等等能上的都上。讲究的是种类的不同。不过整个传感器架构的成本嘛，你懂得...
2. 数据记录及碰撞分析：
全程Data Recording and Post-Crash Behavior analysis。主要是对智能驾驶系统的数据进行保存并记录到云端后台（包括碰撞事故后的碰撞行为分析），用于优化智能驾驶系统使用。
3. 人机接口的相关安全设计（HMI）：
比如，Fallback时，怎么增加一些配套设计，来提醒驾驶员快速地从智能驾驶系统手中来接管车辆。比如，允许驾驶员方向盘脱手后，方向盘振动这招儿就不管用了，无法提醒到驾驶员，可能就需要搞个座椅振动来提醒。
比如，仪表盘界面在人工驾驶和智能驾驶系统驾驶时，要让驾驶员明显的区分出来，做到心中有数，能够一眼就看出来当前是谁在控制车辆。
比如，系统正驾驶车辆时，人手贱（没注意），打了方向一下，结果系统以为人要接管，立马退出了...因此要把方向盘上植入一些压力传感器，检测人握住方向盘的明确信息，如果人要接管，必须有明确的手握方向盘的动作，才算给系统的明确输入，系统才会退出。
4. 法律法规的相关安全设计：
安全设计还有一个维度，就是对法律法规的遵守。例如智能驾驶系统在控制车辆时，如果后面呼啸而来一辆救护车，智能驾驶系统可以识别并响应这种场景，做到避让，而不是堵在前面，甚至可以靠边停车。
比如准确根据地理围栏信息，识别车辆是应该靠左驾驶还是靠右驾驶等。
////////////////////////分割线：以上内容发布于2019.01.28 后续有更新会继续完善。毕竟安全是一个很大的话题 //////////////////////////
////////////////////////分割线：2019.01.29 更新 //////////////////////////
五、智能驾驶系统安全的演化路径 - 从Fail-Safe到Fail-Operational：
Fail-Safe System （失效保护系统）的特点：
Deactivate / Degrade function
即功能退出或功能降级。功能退出，即让系统稳定到一个Safe State安全状态（注意，只是保护系统自身！也就是说系统它发现它自己“生病”了，然后就报告老板：“我生病了，先回家了”然后工作一撂，头也不回地回家了...）；功能降级跟上面类似，虽然没有“回家”，但是换成跟老板讲“这个工作搞不定了，不搞了”。
Report a diagnostic error 报告并记录一个诊断故障
Inform the driver 通知驾驶员
评价：这种系统设计显然无法满足前文提到的L3-L4-L5级别自动驾驶要求的Fallback（MRC）设计需求。因为驾驶员还没反应过来，你系统直接撂挑子了，不给个缓冲时间，也不负责把车降低到最小风险状态（靠边停车），不得出事故啊！
Fail-Operational System（失效工作系统）的特点：
Fail-Operational 经常在航空设计中使用。就是发生故障了，也得“带病工作”，不能请假！坚持把飞行任务完成，或者坚持让飞机顺利降落。
在Fail-Operational系统中，Safe State有了更高的要求，其实就是对标MRC最小风险状态的要求：
L3级要求7-15秒的系统“带病”驾驶，并等待驾驶员在环（Driver in loop）；L4-L5要求几分钟的系统“带病”驾驶能力。
假如驾驶员仍旧不理会系统的报警请求，那么L4-L5级自动驾驶系统就会自动执行靠路边停车（Pull Over）。L3级别（TJP）可以直接停大马路上，至于有追尾的危险，对不起，系统没那么大能耐了，驾驶员自求多福吧！
Fail-Operational系统的冗余程度：
上文已经介绍了系统冗余设计，但是，为什么要那样设计呢？？？
2oo3冗余方案。在航空航天领域，关键组件的冗余都是3倍冗余（triple redundancy）。然后搞一个投票器（Voter）来对比三者之间的输出，做真实性校验（plausibility check）。这种设计方式叫做“two out of three system approach”, 即2oo3冗余方案。即便一个挂了，另外两个仍旧能够输出经过真实性校验的稳定输出，系统完全不需要Fallback，继续飞行就可以了；待飞行结束后，再维修坏掉的组件就可以了。
但是，2oo3冗余方案的成本太太太高了。民用汽车不可能采用这种设计方法。
1oo2D冗余方案。所以，汽车行业搞了一个“简配版”方案，“one out of two with high diagnostic coverage”方案。这个1oo2D方案跟2oo3方案不一样的点在于，相互之间要以更高的诊断覆盖率来相互校验对方，检查对方是否“挂了”。如果一个组件失效了，还有另一个组件撑着。
这个方案虽然不如2oo3方案完美，但是已经足够满足Fallback（MRC）需求了。而且成本优势明显。（不考虑成本的量产项目都是耍流氓！你又不是NASA和军方，你只是盈利性民营企业，要自负盈亏的）。
1oo2D*冗余方案。跟上面类似的方案，但是为啥要加个星号呢？其实这个方案就是上文提到的最流行的冗余方案：2个域控制器（two computer）+1个智能前视摄像头模块（one smart sensor）的配置。一个域控制器挂了，还有另外一个正常工作；且正常工作的域控制器还可以与智能前视摄像头模块校验数据。smart senor（智能前视摄像头模块）中也有一些关键功能（感知直接来自自身数据，不依赖外部，比如智能前视摄像头模块本身就采集视频数据），比如AEB紧急制动之类的。可以在控制器们都有问题后执行紧急操作。
- 用户评论
