Public Docs
【模型量化】深度学习模型量化 & 量化理论 & 各平台的量化过程 & 硬件加速
【TVM】TI关于TVM的使用测试与分析
【LLM&LVM】大模型开源工程思维导图
【北航卓越工程师】《汽车前沿技术导论:智能驾驶》讲义
【工具链】Yocto使用介绍——使用Yocto创建一个树莓派的系统镜像
【工具链】使用ssh+dialog指令设定服务器指定用户仅容器访问
【推理引擎】一篇关于模型推理的详细对比与学习
【推理引擎】关于TVM中的Schedule优化详解(On going)
【LLM微调】使用litgpt进行私有数据集模型微调的测试总结
【TVM】在TVM Relay中创建一个自定义操作符
【STT+LLM+TTS】如何使用语音转文字模型+大预言模型+语音生成模型完成一个类人的语音交互机器人
【RAG】 通过RAG构建垂直领域的LLM Agent的方法探索
【RAG】GraphRAG精读与测试(On going)
【AI Agent】MetaGPT精读与学习
【AI Base】Ilya Sutskever 27篇必读论文分享清单
【Nvidia】Jetson AGX Orin/ Jetson Orin nano 硬件测试调试内容(On going)
【BI/DI】LLM Using in BI Testing Scenario (On going)
【Nvidia】How to Activate a Camera on Nvidia Platform in Details
【RAS-PI】树莓派驱动开发
【行业咨询阅读】关注实时咨询和分析
【mobileye】2024 Driving AI
【mobileye】SDS_Safety_Architecture
【yolo】yolov8测试
【nvidia】Triton server实践
【alibaba】MNN(on updating)
【OpenAI】Triton(on updating)
【CAIS】关于Compound AI Systems的思考
【Nvidia】关于Cuda+Cudnn+TensorRT推理环境
【BEV】BEVDet在各个平台上的执行效率及优化(On Updating)
【Chip】AI在芯片设计和电路设计中的应用
【Chip】ChiPFormer
【Chip】关于布线的学习
【Chip】MaskPlace论文精读与工程复现优化
【gynasium】强化学习初体验
【Cadence】X AI
【transformer】MinGPT开源工程学习
【中间件】针对apollo 10.0中关于cyberRT性能优化的深度解读和思考
【Robotics】调研了解当前机器人开发者套件(on updating)
【Robotics】ROS CON China 2024 文档技术整理与感想总结(上2024.12.7,中2024.12.8,下场外产品)
【algorithm】关于模型、数据与标注规范的平衡问题
【nvidia】DLA的学习了解与使用
【nvidia】构建nvidia嵌入式平台的交叉编译环境(其他环境平台可借鉴)
【2025AI生成式大会】2025大会个人总结
【Robotics】 Create Quadruped Robot RL FootStep Training Environment In IsaacLab
文档发布于【Feng's Docs】
-
+
首页
【mobileye】SDS_Safety_Architecture
[【附件】SDS_Safety_Architecture.pdf](/media/attachment/2024/12/SDS_Safety_Architecture.pdf) * 基于Mobileye 在2017年提出的RSS(Responsibility-Sensitive-Safety, mobileye对于系统可靠性和安全性的理论计算和场景分解方法),用于指导SDS(Self-drivingcar system)面对不安全情况下的决策制定方法,以及预期非安全情况下的解决方案。 * Mobileye认为,只要将所有危险场景的划分足够清晰和细致,就能尽可能的针对各个安全风险场景提供尽可能的解决方案,以降低事故率,增大MTBF。 * 例如,mobileye将硬件划分为传感器、计算单元和执行器。针对于计算单元失效的情况,提供额外的基于pcie的冗余方案,以降低该失效场景发生的可能性。针对有可能出现的罕见场景,如一个婴儿出现在行驶道路上,使用一些和婴儿类似的洋娃娃,增大类似场景在样本中出现的概率,从而指导系统对类似场景的应对策略。(还引用了天文学家,卡尔·萨根博士的名言“缺乏证据并不意味着证据的缺乏”,提醒人们不要犯“无知即证据”的逻辑谬误)。而对于黑天鹅事件,mobileye指出是通过对系统进行充分的冗余设计,使黑天鹅事件的发生总是涉及到至少两个子系统发生故障。 * mobileye还通过一些抽象和假设,对MTBF在各个场景下进行了理论的数学计算。计算得到的的第一个引理是,对于两个相互独立的子系统,如果以10s为单位,同时失效发生的时间要远高于MTBF。 * 当引入子系统或者冗余系统后,遇到的新问题就是两个子系统的信息如何融合以谁为准的问题。对于一些场景mobileye认为是比较简单的,但是对于一些由深度学习给出的结果,想要融合就比较困难,因为对于模型自己去融合信息可能会因为缺少“失效场景”的数据而导致不准确,尤其是对于一个端到端的系统。Mobileye用了一个叫“The shaortcut Learning Problem”的场景予以说明。 * 基于以上信息,mobileye提出了另一种近似“worst-case fusion”即,两个子系统如果同时提出刹车才刹车,有任何一个子系统说没必要刹车,就不刹车。但是同样,这样的近似会导致误报的出现。为了消除这个现象,系统又提出了第三个子系统,用于“majority vote”即少数服从多数。但是由于大多数子系统的输出不只有二值化特性,所以出现了PGF(Primary,Guardian,Fallback)。P、G允许输出多种,而G只能输出binary。如果P优于则G=1,反之G=0。  * 关于独立失效实践,mobileye用理论计算给出了两个相对独立的计算单元的失效分析计算和功能安全等级。(`个人理解这里面还有一个点是如何确认两个计算硬件和软件各自就是相对独立的,是否需要两套独立的供电系统、独立的线束等等,否则如何能够明确两个计算硬件相对独立。文章只是给出了如果两个计算硬件独立的失效分析计算,以及应该不需要三重冗余,但是对于如何满足和达到计算硬件的独立失效系统的整体设计,没有给出明确说明。从工程角度讲,存在很多设计上的注意事项。例如对于大算力系统,如果硬件要进行水冷或者风冷,那水冷系统和风冷系统是否也要进行独立考虑,整个系统的复杂度并不是二倍关系。或者是否有些部分不需要冗余,这个对于不同的设计方案和要求来说,工程化区别很大。`)  * mobileye指出,在SDS系统设计时,对于所有关键的通讯通道,都设计了两种不同类型的通讯方式。表现在,ecu计算单元会同时跟两个板子的mcu通讯,通讯会采用CAN和以太网两种形式(`CAN和以太网带宽是否满足同一个场景的需求?`)所有传入ECU的数据都会经过CAN和以太网两种方式;板板互联会通过PCIE和以太网两种不同方式;MCU2MCU会使用CAN和以太网两种不同方式;etc。 * 关于感知系统的失效分析是一个比较有意思的部分,mobileye将感知功能(物体检测,车道线检测,红绿灯检测,视角检测)各自用PGF框架做了设计与分析。 * 疑问1: 文中提到的硬件失效和执行器失效感觉执行器失效是硬件失效的一种,并且文中关于相关失效的解释,每种失效质检也存在一定的交际如,Software bugs和perception failures,这一段说明有点凑数的感觉。  * 疑问2: 关于传感器失效的部分讲解比较粗糙。例如最后提到的关于动态物体SDS会比较相机检测结果和激光、雷达的检测结果,来对比是否失效。`那这跟感知模块做融合的区别是什么?如果传感器布置不存在overlap怎么办,对于low level的融合,没有单独传感器的输出结果怎么办?还是说整个SDS的设计都是围绕high leve fusion的系统?这是否只是针对技术方案滞后抱残守缺的一种合理化解释?可解释=安全,不可解释=不安全?`
dingfeng
2024年12月17日 16:02
459
0 条评论
转发文档
收藏文档
上一篇
下一篇
评论
手机扫码
复制链接
手机扫一扫转发分享
复制链接
Markdown文件
PDF文档
PDF文档(打印)
分享
链接
类型
密码
更新密码