在ADAS传感器（Sensor）解决方案的取舍考量中、摄像头（Camera）、激光雷达（Lidar）、雷达（Radar）三者常常会被用来做比较。论成本，Camera派和Radar派吐槽Lidar实在太贵不适于量产。论局限，Radar派和Lidar派诟病Camera容易受到照明因素的影响。论分类，Camera派和Lidar派嘲笑Radar分不清摩托车和自行车。综合多种因素，各路专家进行总结，整理出类似于下表这样的表格对比优劣决定技术路线进行取，表格虽然不是行业标准，但也覆盖了传感器（sensor）技术路线选择的主要考量的10个重要因素——成本（cost）照明（illumination）噪声（noise）距离（range）分辨率（resolution）天气（weather）速度跟踪（velocity tracking）高度跟踪（height tracking）距离跟踪（distance tracking）目标分类（classification）结合10项因素，可得到三种方案的雷达图如下，可谓是各有所长但还是无法确定何种方案更为适合，因而在实际工作中需要建立一定的评估机制。加上实际过程中考量的权重，例如在可接受范围内对成本的考量一般比对分辨率这一因素的权重会更高，根据如上表格的评价进行评分（0-1000分），各因素的评分值乘以相应权重再相加，整理分值结果如下。由于是个人主观评分缺少一定的专业性，在实际工作中应根据现实情况调整模型和评分。因素(factor)权重(weight)摄像头(Camera)激光雷达(Lidar)雷达(Radar)成本(cost)20846照明(illumination)10488噪声(noise)5844距离(range)15866分辨率(resolution)5864天气(weather)15648速度跟踪(velocity tracking)5668高度跟踪(height tracking)5684距离跟踪(distance tracking)5488目标分类(classification)15886整体(overall)100690590640虽然三者各擅胜场，但综合当下的因素看来，摄像头（Camera）方案的分值最高为690，超过雷达（Radar）的640和激光雷达（Lidar）的590，从这个角度也印证了为何特斯拉选择纯视觉路线的自动驾驶方案。而另一方面，这三条路线评分也随着技术发展发生着动态的变化，例如在特斯拉视觉方案的FSD随着软件技术的加持便可能将环境局限的影响降至最低，而在特斯拉眼中看为昂贵的激光雷达（Lidar）经过华为的入局便可能将成本大大降低。那么在雷达(Radar)这条路线上，有哪些技术手段又能将其加分呢，答案便是机器学习（Machine Learning），以雷达分值较低的目标分类(classification)和高度跟踪(height tracking)这两个维度为例，机器学习便能帮助雷达在这两个方面加分。以下为《人工智能/机器学习从雷达获得最多》一文的个人节选翻译：from-radar分类是车辆识别物体是什么，并更好地预测其行为的方式，这对基于ADAS的所有级别的决策和自动驾驶至关重要。例如，自行车和摩托车有相似的形状和大小，但操作非常不同。要让一辆车对它们做出适当的反应，它必须能够将它们区分开来。分类一直是计算和电力密集型的基于视觉系统的领域。然而，基于视觉的系统包括不必要的信息，如物体的颜色或是否有文字写在上面。在这些系统中，必须丢弃多余的数据，以便ADAS得出相关结论。相比之下，雷达可以更直接地帮助得出这些结论，而且它的性能在恶劣的天气条件下(如雪、雾和大雨)更优越，而且不受照明问题(如黑暗或阳光直射)的影响。Aptiv的先进机器学习技术能够以雷达为中心，更高效地判断物体是其他车辆、行人、自行车还是其他易受伤害的道路使用者，从而对这些物体可能的行为做出更好的结论。该技术为优化现有硬件提供了巨大的机会，同时利用雷达的现有优势，如在杂乱环境中工作的能力，看到周围的障碍，并利用低水平雷达效果来提高高度估计。如果目标分类(classification)和高度跟踪(height tracking)这两个维度的分值能提高到8分，那么雷达路线的能力值将大幅提升——再重新计算分值如下：因素(factor)权重(weight)摄像头(Camera)激光雷达(Lidar)雷达(Radar)雷达+AI(Radar + AI)成本(cost)208466照明(illumination)104888噪声(noise)58444距离(range)158666分辨率(resolution)58644天气(weather)156488速度跟踪(velocity tracking)56688高度跟踪(height tracking)56848距离跟踪(distance tracking)54888目标分类(classification)158868整体(overall)100690590640700这样看来，“雷达+AI”的路线便以700分领先成为最优选了，在其他技术路线止步不前的前提下。转载于汽车电子与软件微信公众号

【摘要】首先，介绍传感器布置策略在高级驾驶辅助系统中的重要性，提出高级驾驶辅助系统传感器种类，包含前视智能摄像头、前向和侧向毫米波雷达（77 GHz/22 GHz）、超声波雷达以及环视摄像头，简要阐述各传感器性能特点。然后，以目前某量产供应商方案为例，详细介绍不同传感器性能参数，包括探测距离、探测范围和对外部布置环境的要求。介绍不同传感器独自搭载车辆上可实现的功能和对不同驾驶辅助级别、不同功能组合下的不同传感器的融合策略。最后，介绍如何将不同传感器合理安装到车辆上，根据需要达到的性能要求和探测范围冗余性，提出具体实施方案，并对其布置要求进行细化解析说明。主题词：自动驾驶 雷达 摄像头 传感器 布置1 引言随着科技的进步、自动驾驶技术的快速发展，目前越来越多汽车配备了高级驾驶辅助系统或辅助驾驶系统，自动驾驶汽车在SAE J3016TM自动驾驶等级中被归类为五级自动驾驶。自动驾驶运用了多种传感器（超声波雷达、毫米波雷达、智能摄像头、高清/标清摄像头、激光雷达等），王田等对自动驾驶感知系统中的摄像头、激光雷达、毫米波雷达等主要传感器进行了功能介绍。袁秀珍围绕自动驾驶汽车传感器技术产业开展分析，阐述了重要组成的硬件应用，如激光雷达、摄像头、超声波传感等。在实现自动驾驶的开发价值链中，传感器的零件开发主要集中在国内外汽车零部件供应商，而整车功能集成则在由主机厂完成。张燕咏等提出一种基于多模态融合的自动驾驶感知融合算法，很多工程师往往将开发精力集中在算法开发与系统设计，但是经常出现的情况是，成功运用的传感器硬件和软件策略，在部分主机厂车型上效果很好，但是在另外部分主机厂的运用上效果一般，甚至达到反面效果。这是因为在自动驾驶研发中，每一个环节的考虑必不可少。作为闭环开发，好的算法是基于传感器前端感知的精准探测，各类不同的硬件传感器，对于传感器探测性能提出了不同程度的要求，而对于探测性能影响尤为重要的一点就是传感器的布置位置和布置方式。本文依据自动驾驶中运用较多的传感器的探测性能特点，对布置方式做一个简单介绍。2 高级驾驶辅助系统传感器介绍高级驾驶辅助系统（Advanced Driving Assistance System,ADAS）是利用传感器，在汽车行驶过程中实时感应周围的环境，收集数据，感知融合并对感知数据进行决策分析，最后对车辆进行控制和对驾驶员进行预警。摄像头能获取包括物体颜色、外形、材质等丰富的环境信息，并且2D计算机视觉已取得很多进展,该领域有许多先进的算法用于信号灯检测、物体分类等。毫米波雷达能够获取精准的距离信息,穿透能力强,能够抵抗天气和环境变化的影响,可实现远距离感知探测。目前量产的自动驾驶汽车上的传感器种类有4种，数量为22个前视智能摄像头：常用有单、双和三目，主要应用于中远距离场景，能识别清晰的车道线、交通标识、障碍物和行人，但对光照、天气等条件很敏感，而且需要复杂的算法支持，对处理器的要求也比较高。毫米波雷达：主要有用于中短测距的24 GHz雷达和长测距的77 GHz雷达2种毫米波雷达可有效提取景深及速度信息，识别障碍物，有一定的穿透雾、烟和灰尘的能力，但在环境障碍物复杂的情况下，由于毫米波依靠声波定位，声波出现漫反射，导致漏检率和误差率比较高。超声波雷达：主要应用于短距离场景下，发送超声波与接收反射超声波信号，并把探测结果发送给控制器。超声波的能量消耗较缓慢，穿透性强，测距的方法简单，成本低。但是它在速度很高情况下测量距离有一定的局限性，当汽车高速行驶时，使用超声波测距无法跟上汽车的车距实时变化，误差较大。超声波散射角大，方向性较差，在测量较远距离的目标时，其回波信号会比较的弱，影响测量精度。但是，在短距离测量中，超声波测距传感器具有非常大的优势。环视摄像头：主要应用于短距离场景，可识别障碍物，但对光照、天气等外在条件很敏感，技术成熟，价格低廉。随着技术的不断发展进步，摄像头的像素也在逐步提升，从最开始的30万像素，提升到目前的100万像素，未来3年内200万像素的摄像头将会普及。3 传感器实现功能配置组合高级驾驶辅助系统的不同传感器之间的组合，可以实现不同的功能，上述介绍的22个传感器全部搭载到整车，可实现ADASL1/L2/L3，下面介绍详细的子功能。3.1 前向智能摄像头和前向毫米波雷达前向智能摄像头实现AEB-C（自动紧急制动-车）、LDW（车道偏离预警）、LKA（车道保持辅助）、TSR（交通标志识别），实现L1级驾驶辅助。道路实际情况探测精准（如车道线、隧道、匝道、限速等），但是距离探测不精准。其代表性能参数见表2。前向毫米波雷达（77 GHz）实现ACC（自适应巡航）、AEB-C（自动紧急制动-车）、FCW（前向碰撞预警），实现L1级驾驶辅助。距离探测精准，但是无法预测实际情况（如车道线、隧道、匝道、限速等）。其代表性能参数见表3。前向智能摄像头和前向毫米波雷达融合，实现ACC、AEB-C/P自动紧急制动-车/人）、LDW、LKA、TSR、TJA（交通拥堵辅助）、ICA（智能巡航辅助），能实现L2级驾驶辅助(图1)。距离和道路信息均是融合后的数据，探测精准。3.2 侧向毫米波雷达（角雷达）侧向毫米波雷达（24 GHz）实现盲区监测功能，有2种实现方式。后侧方面2个毫米波雷达，实现BSD（盲区监测）、LCW（变道碰撞预警）、RCTA（后方交通穿行预警）和DOW（开门预警）功能；后侧2个毫米波雷达+前侧2个毫米波雷达，除了实现以上功能外，还能实现FCTA（前方交叉路口预警），支持L2级以上的高级驾驶辅助功能。随着科技进步，侧向毫米波雷达性能也在逐步提升。侧向毫米波雷达（4个）、前向毫米波雷达（1个）、前向智能摄像头（1个）组合使用，可实现L2+（或L3-）级自动驾驶。在L2级自动驾驶上，增加TJA/HWAML（高速公路驾驶辅助—多车道）、ALC（主动变道辅助）、TLC（触发式变道辅助）、ELK（紧急车道保持）、ESA（紧急转向辅助）、JA（十字路口辅助）、全方位预警（含BSD/DOW/RCTA/FCTA/LCW）(图2)。可高速公路工况下，实现自动驾驶功能。3.3 超声波雷达根据超声波雷达短距离探测目标物的特点（表6），超声波雷达根据不同数量组合，可实现PDC（倒车雷达）、APA（自动泊车辅助）和BSD（盲区监测）功能。后保险杠上安装4个超声波雷达，可实现PDC功能，有些车辆在前保险杠上同时安装4个超声波雷达（前后共8个超声波雷达），倒车时探测前方障碍物。在前后保险杠侧面安装4个超声波雷达，可实现近距离盲区监测功能，同时结合前后8个超声波雷达，共12个超声波雷达，能实现APA功能。如果车辆侧面安装有毫米波角雷达，实现BSD功能，则侧面的超声波雷达就不用安装。BSD安装超声波雷达的主要要因是其成本优势。超声波雷达不同组合及功能见图3。3.4 环视摄像头AVM（全景式监控影像系统）通过前后左右4个图像传感器（环视摄像头）采集车辆周边环境数据，将影像通过CVBS（标清）/LVDS（高清）传递给全景影像控制器。如果仅在后方装1个摄像头，可实现倒车影像功能。如果同时在前后左右安装4个摄像头，通过对4个摄像头输入图像进行畸变校正及裁剪，实现4个视图及2D俯视图效果集成，3D旋转效果（高清方案）集成，最终通过MP5进行显示。环视摄像头部分重要参数见表7，其布置在整车示意见图4。4 传感器整车布置融合高级驾驶辅助系统的不同传感器之间的组合布置，需要考虑到覆盖范围和冗余性。不同传感器的感知范围均有各自的优点和局限性，现在发展的趋势是通过传感器信息融合技术，弥补单个传感器的缺陷，提高整个智能驾驶系统的安全性和可靠性。覆盖范围：车体360°均需覆盖，根据重要性，前方的探测距离要长（120 m），后方的探测距离稍短（80 m），左右侧的探测距离最短（20 m）。为了保证安全性，每块区域需要2个或2个以上的传感器覆盖，以便相互校验，如图5所示为布置方案。4.1 前向智能摄像头和前向毫米波雷达布置融合前雷达安装位置根据雷达性能参数要求、车身造型，设定合理的布置位置。雷达离地高度（雷达天线轴到地面的距离）推荐50 cm，30 cm到120 cm之间都可接受。离地高度接近30 cm可能会有过多的地面反射信号干扰直接信号接收和降低探测的风险。雷达与保护盖之间的距离大于15 mm（2倍波长，可以避免复杂近场对雷达波束的影响），小于40 mm（以避免过大的雷达波相交面）。雷达横向位置坐标在-30 cm到30 cm之间。雷达如果安装前盖板，对盖板也有特殊要求，比如曲率半径＞600 mm、波束与盖板相交部分厚度均一、型面需要经过仿真测试、材质需要进行材料电性能测试、非喷涂件等。毫米波雷达波束与周边结构间距＞5 mm，与车辆角度-俯仰角、偏航角、侧倾角为0°，雷达FOV与牌照框距离15 mm以上，避免安装牌照后影响雷达探测等等要求。前摄像头最好的垂直安装位置是在挡风玻璃的中心，高度在1 200 mm以上为佳，可以允许偏移挡风玻璃中心线在10 cm以内。偏航角、侧倾角、俯仰角最好为0°附近（±3°）。支架应该安装在干净的玻璃区域，视角区域不能被绢印或者印刷遮挡。摄像头视窗与雨刮轨迹线间距大于30 mm，镜头模块与挡风玻璃的之间间隙应该保证最小1 mm。开口应该由投影在挡风玻璃各层的视角决定，摄像头支架和罩盖上应设计通风孔（开孔面积大于120 mm2），保证空气流通。支架安装在挡风玻璃的位置公差通常是±1 mm（定位）和±2.5°（旋转）。4.2 侧向毫米波雷达（角雷达）布置融合角雷达根据其性能参数要求、车身造型，设定合理的布置位置，车身要预留布置空间。角雷达布置高度要求：过低泥水污物影响雷达，太高离车辆近处的盲区会变大（可能会导致±20°以外无视野），推荐高度在400 mm到1 000 mm之间。要达到盲区最小化，雷达与车辆纵轴线的夹角要在30°到45°之间为宜，雷达与车辆水平面夹角最好控制在90°。雷达FOV视野内无金属，棱线，多层结构或材质，FOV与覆盖件的最大角度为70°，覆盖件要求平整，曲率要求大于350 mm。4.3 超声波雷达布置融合为了实现APA功能，整车上要布置12个超声波雷达，布置数量较多。超声波雷达传感器安装支架上，通过与保险杠蒙皮的粘接固定上。为了最大限度满足探测要求，超声波雷达布置位置提供了具体要求，见图8。布置具体要求有：避免将雷达布置在凹陷于汽车保保杠的表面、避免拍照干涉雷达探测区域、远离热源排气管、大功率灯具等等。4.4 环视摄像头AVM环视系统，共需在车身前后左右布置4个摄像头。前方摄像头安装在前格栅附近区域。后方摄像头安装在后背门牌照灯或附近区域。左右侧摄像头需要安装在后视镜壳底部，需要在左右后视镜中预留一个摄像头的孔位，以便于左右摄像头的安装。摄像头布置时应进行光学校核，保证相邻摄像头影像有足够的重合，并且在摄像头1°的组装误差范围内应能保证图像拼接无黑边，盲区不能超过企业标准所要求。为防止拍摄影像的改变，而导致全景影像无法拼接，摄像头应具有防旋转的定位结构。前后摄像头布置要求：车辆满载时，离地高度≥600 mm；偏离中心平面距离≤50 mm，建议置于中心平面；视轴与车辆XZ平面平行；视轴与车辆Z轴夹角建议45°到75°，光轴与地面线交点距车身最外侧1 000～2 000 mm；盲区视野≤200 mm；摄像头垂直视野在3 000 mm处可完整看到直立于地面3 000 mm高的物体。如图9为环视摄像头（前）布置要求。左右摄像头（后视镜上）布置要求：摄像头前视图，视角与垂直线之间夹角建议20～25°；视角与垂直线之间夹角建议1.5～5°；安装高度大于900 mm；车身突出距离大于100 mm；视野需覆盖车辆前后各10 m位置，且10 m的视野线与后视镜壳体下边缘距离大于1 mm，前后5 m的视野线与光轴面夹角均小于85°，且5 m的视野线与后视镜壳体下边缘最小距离大于1.2 mm；摄像头外突小于5 mm（可调节）。5 结语高级驾驶辅助系统的传感器除了要保证探测范围的覆盖冗余度，在实际安装中，还要符合每个传感器和车辆的安装条件。本文介绍的传感器布置参数是基于某款车型、特定供应商传感器产品进行的总结融合。不同传感器供应商，对布置要求会有细微差异，在实际车型布置过程中，要结合供应商提供的布置要求，以及整车布置、造型，进行适应性调整。免责声明：文章来源于网络，仅供学习交流分享，版权归原作者所有，如果侵权请联系我们予以删除。转载于汽车电子与软件微信公众号

01.前言电脑已经是大家日常生活中不可或缺重要工具，我们使用电脑来浏览网站、收发邮件、编辑照片和视频、浏览社交媒体以及在线会议。在使用电脑的过程中或多或少会遇到系统崩溃，卡顿，软件不响应等等问题。那为何手机经常卡顿/司机？可能是因为部件老化或过热，又或是电脑芯片的一个关键组件失效或者内部接插件接触不良，又或者是软件的BUG从而导致整个系统随机重启。多亏这是安装在电脑中的处理器，最糟糕的结果也只是因为数据的丢失而片刻的沮丧。如果这款处理器安装在您汽车的某个控制系统中，例如转向/制动/智能驾驶，那么后果可能会更严重。所有电子元件都会在某个时间点失效，这是无法更改的事实。而如今，我们发现在我们汽车上越来越多的执行关键功能的电子元件越来越多，涉及转向、制动、智能辅助驾驶等方面。既然电子元件必然会随着时间的流逝出现各种问题， 并且我们的电子电气工程师无法阻止时间的流逝，我们该如何帮助使用我们元件的系统设计人员来避免此类随机事件危及车辆驾乘人员以及其他交通参与者的生命安全？答案就是：功能安全。02.什么是功能安全“功能安全”是指避免由系统功能性故障导致的不可接受的风险。功能安全关注系统故障后的行为，而不是系统的原有功能或性能。在现代工业控制领域中，可编程电子硬件、软件系统的大量使用，大大提升了自动化程度。但由于设备设计中的缺失，以及开发制造中风险管理意识的不足，这些存在设计缺陷的产品大量流入相关行业的安全控制系统中，已经造成了大量的人身安全、财产损失和环境危害事故。为此，世界各国历来对石化过程安全控制系统、电厂安全控制系统、核电安全控制系全领域的产品安全性设计技术非常重视，并且将电子、电气及可编程电子安全控制系统相关的技术发展为一套成熟的产品安全设计技术，即“功能安全”技术。欧美已经颁布了成套的功能安全相关产品指令和设计标准，并深入到各个领域，如：汽车（ISO26262）轨道控制（EN 5012X）、核电(EN 61513)、工业装备及机器控制（EN 62601, EN ISO 13849-1/2）、过程控制(EN 61511)等，国际上，IEC形成的 IEC 61508，IEC 61511 等系列标准已经逐步成为各国家、行业广泛认可的基本功能安全标准，中国也仿效并形成了的相应国家标准，其他行业性功能安全标准也在参照并将逐步形成为国家行业性标准。ISO26262是从电子、电气及可编程器件功能安全基本标准IEC61508派生出来的，主要定位在汽车行业中特定的电气器件、电子设备、可编程电子器件等专门用于汽车领域的部件，旨在提高汽车电子、电气产品功能安全的国际标准，国内对应的标准即为GB/T 34590。随着系统复杂性的提高，软件和机电设备的应用，来自系统失效和随机硬件失效的风险也日益增加，制定ISO 26262标准的目的是使得人们对安全相关功能有一个更好的理解，并尽可能明确地对它们进行解释，同时为避免这些风险提供了可行性的要求和流程。ISO 26262为汽车安全提供了一个生命周期（管理、开发、生产、经营、服务、报废）理念，并在这些生命周期阶段中提供必要的支持。该标准涵盖功能性安全方面的整体开发过程（包括需求规划、设计、实施、集成、验证、确认和配置）。ISO 26262标准根据安全风险程度对系统或系统某组成部分确定划分由A到D的安全需求等级（Automotive Safety Integrity Level 汽车安全完整性等级ASIL），其中D级为最高等级，需要最苛刻的安全需求。伴随着ASIL等级的增加，针对系统硬件和软件开发流程的要求也随之增强。对系统供应商而言，除了需要满足现有的质量要求外还必须满足这些因为功能安全等级增加而提出的更高的要求。故障-错误-失效故障功能安全中定义的故障是指可引起要素或相关项失效的异常情况。故障可以分为永久故障和非永久故障，其分类如下图所示。永久性故障是指发生并持续，直到被移除或修复的故障。也就是说永久性故障发生了必须采取相应的措施才能够使其恢复其正常运行。其中系统性故障一般表现为永久性故障。非永久性故障可以分为间歇性故障和瞬态故障。间歇性故障是指故障一再的发生，然后消失。当一个组件处于损坏的边缘时，或者例如由于开关的电涌(电压的瞬态激烈变化)，间歇性故障可能会发生。某些系统性故障(例如时序混乱)也可能导致间歇性故障。瞬态故障是指发生一次且随后消失的故障。瞬态故障可由电磁干扰引起，其可导致位翻转。比如由于单粒子翻转效应(SEU)和单粒子瞬态脉冲(SET)发生的软错误，均为瞬态故障。(单粒子翻转是宇宙中单个高能粒子射入半导体器件灵敏区，使器件逻辑状态翻转的现象。)错误ISO 26262中定义的错误是指计算的、观测的、测量的值或条件与真实的、规定的、理论上正确的值或条件之间的差异。错误可由未预见的工作条件引起或由所考虑的系统、子系统或组件的内部故障引起。故障可表现为所考虑要素内的错误，该错误可最终导致失效。比如由于宇宙中单个高能粒子射入半导体器件灵敏区，使存储器逻辑状态翻转的单粒子翻转效应SEU，使得软件中某个bit位从0到1或者从1变成0是属于一个软错误(硬件没有损害)。从上可以看出故障，错误和失效的大概关系是故障可引起错误，错误再导致失效。下文会再做详细说明。失效失效，按照ISO26262的定义是要素按要求执行功能的能力的终止。(英文：terminationof the ability of an element to perform a function as required)注：不正确的规范是失效的来源之一。在这里失效针对的是功能的丧失或者终止。比如对于电机控制器来说，其主要的功能之一是根据整车控制器VCU的扭矩请求，对电机进行转矩和转速的控制，因此无论输出的扭矩非预期的偏大或者偏小都是一种失效。1.系统性失效和随机硬件失效在功能安全中依据失效的原因可以将失效分为两种：系统性失效和随机硬件失效。而功能安全的主要目的就是尽可能的将由于这两类失效导致的整车层面安全风险降低到一个可以接受的水平。(1)系统性失效(systematic failure)以确定的方式与某个原因相关的失效，只有对设计或生产流程、操作规程、文档或其它相关因素进行变更后才可能排除这种失效。系统性失效存在三个特征：A- 仅仅进行正确维护而不加修改的情况下，无法消除故障。B-通过模拟失效原因可以使其重复出现。C-是人为错误引起，失效原因比如：安全要求规范的错误；硬件的设计，制造，安装，操作的错误；软件的设计和实现的错误等。软件故障和部分的硬件故障是属于系统性故障。比如coding的时候没有考虑使用数据类型的错误，某变量(比如精度为1，offset为0)本应该使用U16的，结果用成了U8，使得计算的最大数值只能到255。这里的软件bug是属于系统性失效。(2)随机硬件失效(random hardware failure)按照ISO 26262的定义，随机硬件失效是在硬件要素的生命周期中，非预期发生并服从概率分布的失效。并且可在合理的精度范围内进行预测。非预期发生的含义是尽管硬件的设计是正确的，比如电子元器件的选型，电阻值，电容值，电路设计等都是正确的，且器件是符合质量标准的。但是却无法预知在哪里发生，以怎样的形式发生的失效。服从概率分布的含义是失效可以在合理的精度范围内进行预测。比如通过可靠性或者分析得到失效率。随机硬件失效的起因是由于物理过程，比如疲劳、物理退化或环境应力等。比如上面提到的位翻转，比如电阻的开路，短路，阻值漂移等等。2．相关失效和非相关失效此外功能安全中还定义了相关失效和非相关失效。相关失效是指失效同时或相继发生的概率不能表示为每个失效无条件发生概率的简单乘积。比如当失效A和失效B同时发生的概率不等于两个失效概率的乘机，用数学关系式表示为Pab =Pa*Pb，失效A和B可被定义为相关失效。反之非相关失效可以表示为每个失效无条件发生概率的简单乘积。相关失效可以分为共因失效和级联失效。共因失效是指在相关项中，有一个单一特定事件或根源引起的两个或多个要素的失效。如下图所示。我们无法避免随机故障的发生，因此，功能安全在系统中构建安全监控和缓解机制，从而解决随机故障。功能安全机制可持续监控汽车中的制动信号，从而检查它是否偏离预期范围。如果确实偏离了预期范围，安全机制会标记出可能出现的问题并需要对其进行检查。故障，错误和失效之间的关系故障，错误和失效之间的关系如下图所示。图中从三个不同类型的原因(系统性软件问题、随机硬件问题和系统性硬件问题)描述了故障到错误并从错误到失效的发展过程。系统性故障起因于设计和规范的问题；软件故障和部分硬件故障是系统性的。随机硬件故障起因于物理过程，比如疲劳、物理退化或环境应力。在组件层面，每个不同类型的故障会导致不同的失效。然而，组件层面的失效是相关项层面的故障。04.为一切可能性做好准备功能安全中描述的问题其实也会经常出现在我们日常的家庭和工作场所。如果您曾经注意到，你的手机因为长时间放在阳光下而自动关机，这是因为手机实时的在监控手机的温度，一点温度上升到危险阈值，手机就会自动关机防止电池过温起火，这就是一个典型的功能安全机制在起作用。功能安全无法避免随机硬件故障的发生，但是功能安全可以在系统中构建安全监控以及对应的安全机制，更好的应对随机故障，降低安全风险。例如，功能安全机制可持续监控汽车中的某个传感器的信号，从而检查它是否偏离预期范围。一旦发现偏离了预期范围，安全机制就会被触发，将系统带入到预先定义好的一种工作状态当中，这这种预定义的状态下，对应功能不会产生安全风险。为了预测这些潜在的危险，系统层面的功能安全工程师必须了解这些电路层面危险故障的所有可能原因、发生的可能性以及如何设计对应的软硬件实现对故障的及时&准确的诊断。实现了功能安全的集成电路可以将风险降低到可接受的水平，并在失效模式、影响和诊断分析 (FMEDA) 中具体说明其诊断覆盖范围。然而，要确保产品满足功能安全要求，为应对随机硬件失效做好充足准备只是其中之一。另一个风险来源是开发过程本身的系统失效。因为无论诊断覆盖率多高，打造功能安全应用的时候都必须遵循合适的流程才能有效避免人为因素引入的失效（系统性失效）——这也是标准体系最大的益处。无论功能安全措施设计得如何完善，严格的质量管理流程都是实现功能安全的前提条件之一。开展功能安全活动的时候，“循规蹈矩”非常重要。这个过程必须从一开始就将安全纳入考虑，而且还必须营造支持安全的文化。完整的开发流程必须包含以下几个重要方面：安全管理：包括团队组织架构，具体内容如：明确不同职位的定义和职责、打造安全文化、定义安全生命周期，定义功能安全支持级别。安全生命周期的设定包括制定一份成功计划，选择合适的开发工具，确保团队接受充分的培训。需求管理和故障检测及控制措施（功能安全需求）的可追溯性。为精确实现需求追溯，需求本身定义必须要明确，精准，且具备唯一性。追溯等级取决于完整性的要求，文件可以高等级；产品则需要从故障检测到验证等各个环节面面俱到——计划过程不得空穴来风，必须经过详细验证。文档管理和问题管理。勘误表必须得到妥善管理和使用。为实现文档的精确管控，文档本身版本信息和识别ID必须要明确，精准，且具备唯一性，文档变更的记录也需要保证完整性。产品在开发过程中对于设计和验证阶段所出现的所有功能安全相关的问题，从问题出现->关闭的整个过程必须经过详细记录和验证。05.总结最后，我们再来强调一下功能安全标准中对功能安全的定义“避免由系统功能性故障导致的不可接受的风险”。标准的描述从来都是严谨而晦涩，简单来说，就是一个功能在它的使用过程中如果出现故障了会带来伤害，这个功能就是功能安全相关的。因此Functional Safety翻译为“功能的安全”更为贴切。举个略显不恰当的例子：如一把椅子（不使用标准里说的E/ E，是因为这些产品和系统比较复杂，功能比较多不如椅子这种描述的直观）。椅子之所以成为椅子，其中核心的一点就是其设计、生产和使用的目的是让人坐在上面。“让人坐”是一把椅子的核心功能。一把不能坐的椅子不能称其为椅子。明晰了椅子“功能”后，我们可以将椅子的“功能安全”描述为：一把椅子在人坐的时候应该是没有危险的，不会倒、不会扎到人等，即人坐到椅子上的时候不会产生伤害。安全，按一般的概念是没有危险，不受威胁，不出事故。按照这样的概念，安全是不可控制的。因为这是一个绝对安全的概念，而绝对安全是不存在的。但是在ISO 26262中将安全定义为“不存在不可接受的风险”，这样就将绝对化的安全转化为相对化的风险控制，使得可以通过控制风险的手段来解决安全问题，为安全的实现提供了可供遵循的路径—“功能的安全的本质就是控制风险”。功能安全是一个复杂而庞大的体系，涉及的内容多而繁杂，而要更好地理解功能安全的端到端、全系统和全生命周期的科学理论与方法，了解和掌握就是功能安全的基本概念非常必要的且重要的。作者：极氪软件及电子中心 木蓦 

2.2时序监控时序是嵌入式系统的一个重要属性。安全行为要求在正确的时间内执行系统操作和响应。正确的时间可以用一组必须满足的时序约束来描述。然而，AUTOSAR SWC本身无法确保正确的时机。这取决于AUTOSAR运行时环境和基础软件的适当支持。在集成过程中，需要确保AUTOSAR SWC的时序约束。2.2.1故障模式根据ISO26262，以下与时序和执行相关的故障可被视为 SWC之间干扰的原因：阻塞执行死锁活锁执行时间分配不正确软件要素之间的同步不正确时序保护和监控可以描述为对以下属性的监控：监控任务在指时序间调度，满足执行时间预算，并且不独占OS资源。为了保证与安全相关的功能将遵守其时序约束，应检测并处理垄断CPU的任务（例如CPU负载过重，太多中断请求）。2.2.2描述AUTOSAR提供以下时序监控机制：使用 OS的时序保护机制。使用Watchdog Manager进行时序程序流监控。本章将解释Watchdog Manager在实现应用软件时序监控方面的应用。Watchdog Manager还引入了一种称为逻辑监控的机制，该机制可以与死线监控结合使用，以提供高诊断覆盖率。此外，本章还将概述AUTOSAR OS的时序保护机制。2.2.2.1受监控实体Watchdog Manager监控AUTOSAR ECU中应用程序软件的执行。监控的逻辑单元称为监控实体。在AUTOSAR中，受监控实体和架构构建基块之间没有固定的关系。通常，受监控实体可以表示一个SWC或SWC的一个Runnable、一个BSW模块或CDD，具体取决于开发者的选择。受监控实体中的重要节点被定义为检查点。受监控实体的代码与Watchdog Manager的函数调用交互。这些调用用于向Watchdog Manager报告已到达检查点。2.2.2.2Watchdog ManagerWatchdog Manager是AUTOSAR架构的基础软件模块。Watchdog Manager将看门狗硬件的触发与软件执行的监控联系起来。当检测到对程序执行的时态和/或逻辑约束的违反时，将采取许多可配置的操作来从此故障中恢复。Watchdog Manager为时序程序流监控提供以下机制：活体监控：定期监控实体对执行频率有限制。通过活体监控，Watchdog Manager会定期检查受监控实体的检查点是否已达到给定限制。这意味着Watchdog Manager会检查受监控实体的运行频率是否太高或太低。活体监控是使用单个检查点执行的，没有切换。受监控实体必须周期性地调用检查点，以发出其及时操作的信号。OS定期执行Watchdog Manager以验证检查点参数。受监控的实体也可以通过多个活体监控实例进行监控，因此每个活体监控都包含一个独立的检查点。死线监控：非周期性或周期性监控实体对两个检查点之间的时间安排有单独的限制。通过死线监控，Watchdog Manager检查受监控实体的两个检查点之间的转换时间。这意味着Watchdog Manager会检查受监控实体中的某些步骤所花费的时间是否在配置的最小值和最大值之内。如果从未到达第二个检查点，则死线监控将无法检测到此问题。出现此问题的原因是，在调用第二个检查点后，Watchdog Manager将执行时序检查。2.2.2.3 OS的时序保护根据AUTOSAR OS规范，当任务或中断在运行时错过其死线时，就会发生实时系统中的时序故障。AUTOSAR OS不提供时序保护的死线监控。死线监控不足以正确识别导致AUTOSAR系统中时序故障的任务或中断。违反死线可能是由不相关的任务或干扰执行的中断引起的。请咨询AUTOSAR OS规范23了解更多详情。在固定优先级抢占式 OS（如AUTOSAR OS）中，任务或中断是否满足其死线取决于以下因素：任务/中断在系统中的执行时间。任务/中断遭受较低优先级的任务/中断阻塞共享资源或禁用中断的阻塞时间。系统中任务/中断的到达间隔速率。为了安全准确地提供时序保护， OS必须在运行时控制这些因素，以确保任务/中断可以满足各自的死线。AUTOSAR OS提供以下时序保护机制：执行时间保护。任务或2类中断的执行时间上限，即所谓的执行预算，通过 OS进行监控，以防止时序错误。锁定时间保护。OS监控资源阻塞、锁定和暂停中断的上限，即所谓的锁定预算。到达时间保护。正在激活的任务或2类中断到达之间的下限，即所谓的时间片，通过 OS进行监控，以防止时序错误。注意：执行时间实施需要硬件支持，例如时序实施中断。如果使用中断来实现时间执行，则该中断的优先级应高到足以“中断”受监控的任务或中断。2.2.3检测与响应Watchdog Manager为时序和逻辑程序流监控提供了三种机制：死线监控、活体监控和逻辑监控。监控机制是静态配置的。对于受监控实体的监控，可以采用多种监控机制。根据每个已启用机制的结果，计算受监控实体的状态（称为局部状态）。当确定每个受监控实体的状态时，然后根据每个局部监控状态，确定整个MCU的状态（称为全局监控状态）。根据每个受监控实体的局部监控状态和全局监控状态，Watchdog Manager会启动许多机制来从监控失败中恢复。这些范围从受监控实体内的局部错误恢复到ECU的全局重置。Watchdog Manager可以采用以下错误恢复机制：受监控实体中的错误处理如果受监控实体是SWC或CDD，则Watchdog Manager可以通过RTE模式机制通知受监控实体有关监控情况。然后，受监控实体可以采取措施从该故障中恢复。Watchdog Manager可能会在检测到监控故障时向诊断事件管理器（DEM）注册一个条目。受监控实体可能会根据该错误条目执行恢复操作。分区关闭如果Watchdog Manager模块在位于不受信的分区中的受监控实体中检测到监控故障，则Watchdog Manager模块可以通过调用BswM请求分区关闭。通过硬件看门狗重置Watchdog Manager向看门狗接口指示看门狗接口何时不再触发硬件看门狗。在硬件看门狗超时后，硬件看门狗将重置ECU或MCU。这导致ECU和/或MCU硬件的重新初始化以及软件的完全重新初始化。立即复位MCU如果需要对监控故障立即做出全局响应，Watchdog Manager可能会直接导致MCU复位。这将导致MCU硬件和完整软件的重新初始化。通常，MCU复位不会重新初始化ECU硬件的其余分区。注：AUTOSAR文档“应用程序级别的错误说明”提供了有关错误处理的其他信息。在文档中，解释了如何执行错误处理以及可以从何处获取所需数据（例如替代值）。此外，本文档还详细介绍了如何在AUTOSAR中执行 OS-Applications/分区终止和重新启动。2.2.4限制检查点的粒度不是由Watchdog Manager固定的。很少有粗制的检查点会限制Watchdog Manager的检测能力。例如，如果应用程序SWC只有一个检查点，指示循环可运行已启动，则Watchdog Manager只能检测此可运行已重新启动并消除时序约束。相反，如果该SWC在可运行的每个块和分支上都有检查点，则Watchdog Manager也可能检测到该SWC的控制流中的故障。检查点的高粒度会导致Watchdog Manager的复杂和大量配置。死线监控有一个弱点：它只检测延迟（当报告结束检查点时），但它不检测超时（当根本没有报告结束检查点时）。不支持死线监控（即开始1、开始2、结束2、结束1）的嵌套。每个受监控实体具有多个检查点的“活体监控”功能在“Watchdog Manager规范”中未一致地指定。目前，建议每个监控实体仅支持一个活体监控检查点。为了关闭或重新启动（作为错误响应）包含受监控实体的分区，集成代码（ OS-Applications的重新启动任务）通过调用Watchdog Manager的可用函数来停用（或停用+激活）受影响分区的所有受监控实体。这有点复杂，在Watchdog Manager规范文档的未来版本中被认为是Watchdog Manager的新加功能。库无法调用BSW，因此库不能由Watchdog Manager监控。但是，可以通过在模块的代码中放置库调用之前和之后的检查点来使用死线监控，以监控库实例运行。如何使用受监控实体ID标识BSW模块尚未标准化。引用来源：AUTOSAR document 2021转载于汽车电子与软件微信公众号

1. 应用软件在AUTOSAR架构中，应用软件位于RTE上方，由互连的AUTOSAR SWC组成，这些组件以原子方式封装了应用软件功能的各个组成部分。AUTOSAR SWC独立于硬件，因此可以集成到任何可用的ECU硬件上。为了便于ECU内部和内部的信息交换，AUTOSAR SWC仅通过RTE进行通信。AUTOSAR SWC包含许多提供内部功能的函数和变量。AUTOSAR SWC的内部结构，即其变量和函数调用，通过头文件隐藏在公众视野之外。只有外部RTE调用才会在公共接口上生效。AUTOSAR SWC还包含必须在运行时调用的函数。这些C函数在AUTOSAR中称为Runnables。Runnables不能由它们自己执行;它们必须分配给 OS的可执行实体。可以通过将Runnables的函数调用插入OS任务主体来执行此类分配。然后，Runnables在调用方OS-Task的上下文中循环执行和/或事件驱动。Runnables对任务的分配是根据图3和图4执行的。图3：AUTOSAR分层软件架构-Runnables的映射2. OS-ApplicationsAUTOSAR SWC中的Runnables被分配给 OS任务。AUTOSAR OS-Applications是 OS对象（如任务、ISR、调度表、计数器和警报）的集合，它们构成了一个内聚的功能单元。属于同一 OS-Applications的所有对象都可以相互访问。OS-Applications中的 OS对象可能属于不同的AUTOSAR SWC。RTE实现了一个内存区域， OS-Applications的所有成员都可以不受限制地访问该区域，以方便SWC之间有效地进行通信。OS-Applications有两类：受信任的 OS-Applications：“允许受信任的 OS-Applications在运行时禁用监控或保护功能的情况下运行。他们可能不受限地访问内存和 OS模块的API。受信任的 OS-Applications不需要在运行时强制执行其时序行为。当处理器支持时，它们被允许在特权模式下运行。不受信的 OS-Applications：“不允许在运行时禁用监控或保护功能的情况下运行不受信的 OS-Applications。它们限制了对内存的访问，限制了对 OS模块的API的访问，并在运行时强制执行其时序行为。当处理器支持时，不允许它们在特权模式下运行。3. 通信和代码共享一个 OS-Applications可以包含多个AUTOSAR SWC和关联的Runnables。仅允许Runnables直接访问变量并在其各自的 SWC中执行函数调用。SWC的内部函数调用和变量不被其他 SWC公开获取，因为它们的定义不由外部接口的头文件提供，因此不能规划通过变量直接通信并执行其他 SWC的代码。在图5中，代码共享示例对此进行了说明，代码共享只允许在 SWC内使用，而不允许在一个OS-Application的 SWC之间共享。与其他 SWC的通信应通过RTE执行。Runnable4可能无法执行属于SWC2.2的功能。4. 应用软件中的内存分区AUTOSAR ECU中的应用软件可以由与安全相关的 SWC和非安全相关的 SWC组成。应根据ISO26262的要求，确保具有不同ASIL等级的 SWC之间的免干扰性。AUTOSAR OS通过将 OS-Applications放入独占的内存区域，从而不受与内存相关的故障的干扰。此机制称为内存分区。OS-Applications之间彼此受到保护，因为在一个 OS-Applications的内存分区中执行的代码不能修改其他内存区域。AUTOSAR OS规范中的相应要求如表1所示。要求ID要求文本[SWS_Os_00207]OS模块应阻止对 OS的写入访问来自其他不受信的OS-Applications的应用程序的私有数据分区。[SWS_Os_00355]OS模块应阻止从其他不受信的 OS-Applications对 OS-Applications的任务/2类ISR的所有私有堆栈进行写入访问。[SWS_Os_00356]OS模块应阻止从其他不受信的 OS-Applications对 OS-Applications的任务/2类ISR的所有私有数据分区进行写入访问。表1：AUTOSAR OS- OS-Applications的内存分区应用程序软件可以由具有不同ASIL等级的 SWC组成。但是，具有不同ASIL分级的 SWC不应分配给同一个 OS-Applications。内存分区不能提供分配给同一 OS-Applications的 SWC之间的免干扰性。OS仅阻止其他 OS-Applications执行不正确的访问。不会阻止有故障的 SWC修改同一 OS-Applications中其他SWC的内存区域。注意：有关任务级分区的详细信息，请参阅后续分区。5. SWC中的内存分区混合ASIL SWC可能由具有不同ASIL评级的Runnable组成，因此需要一个支持不受这些Runnable之间干扰的执行环境。由于以下原因，无法在不同的内存分区中执行一个 SWC的不同Runnables：内存分区在 OS-Applications级别执行。如图所示图3和图4，一个 SWC只能分配给一个OS-Applications，因此只有一个内存分区。此外， SWC的Runnables只能由一个 OS-Applications的任务调用。如图6所示， SWC的Runnables不能分发到多个 OS-Applications的任务。内存分区不能用于分隔同一SWC中的Runnables。如果有必要让 SWC包含具有不同ASIL的Runnable，并且这些Runnable需要免干扰的独立执行，那么在 OS-Applications级进行内存分区是不够的，内存分区必须在任务级别执行。方法如图7所示。与任务级别的内存分区相关的要求列在表2的AUTOSAR OS规范中。使用弱词“may”表明任务级分区的实现对于AUTOSAR OS是可选的。因此，并非每个AUTOSAR OS实现都支持任务级内存分区。要求ID要求文本[SWS_Os_00208]OS模块可能会阻止从同一 OS-Applications中的所有其他任务/ISR写入对非受信任应用程序的任务/2类ISR的专用堆栈的写入访问。[SWS_Os_00195]OS模块可能会阻止从同一 OS-Applications中的所有其他任务/ISR写入对非受信任应用程序的任务/2类ISR的私有数据分区的写入访问。表2：AUTOSAR OS要求–任务级的内存分区6. 内存分区的实现可以使用内存分区机制在系统和软件级别上实现各种技术安全概念。一个可能的实现，而所有基础软件模块都在一个受信任/监控模式内存分区中执行。某些SWC在逻辑上分组并放在单独的非受信任/用户模式内存分区中（以绿色突出显示）。选定的软件模块与基础软件模块属于同一可信/管理模式内存分区。可能有多个不受信的/用户模式分区，每个分区包含一个或多个SWC。在非受信任/用户模式内存分区中执行SWCs会受到限制，不能修改其他内存区域，而受信任/监控程序内存分区的SWCs的执行不受限制。用于安全相关应用的现代微控制器支持通过专用硬件（内存保护单元（MPU））进行内存分区。注意：假设内存分片将在具有MPU或类似硬件功能的微控制器上实现。使用典型的MPU实现，不受信的应用程序可以允许访问微控制器地址空间的多个分区。访问控制定义为读取、写入和执行访问的组合。MPU的配置仅在监控模式下是允许的。注意：在某些微控制器实现中，MPU集成在处理器内核中。因此，MPU仅控制关联内核的访问。其他总线主站（如DMA控制器和其他内核）不受此分段MPU实例的控制。下表和用例说明了内存保护单元的配置派生自系统要求时的一组可能方案。注意：对于正在使用的特定硬件设备的功能，此表可能不完整。地址空间理由读写执行闪存读取、执行和写入访问不会修改闪存内容。必须首先擦除闪存，并启用其他机制才能写入。注意：从安全角度来看，以下含义：读取和执行外来代码可能用于获取原本不适用于软件的信息。OOORAM对RAM的写入访问可能会导致内存损坏，从而影响软件的行为。OXO外设即使从外设地址空间读取，也可能产生副作用。例如通过对中断控制器的读取访问来执行中断确认，对外围设备的读取访问可能会导致I/O错误。XXX表3：内存保护的配置方案图标说明：X–需要保护O–可选保护注意：从性能角度来看，由于总线争用、接口仲裁等原因，可能会产生副作用。用例1：SWC位于同一分区中。同一分区中的 SWC可以访问彼此的RAM区域，因此可能会损坏彼此的内存内容。根据定义， SWC无法访问外围设备，因为它们不应了解底层微控制器架构。当 SWC被允许直接访问外围设备时，可能会创建不安全的系统。用例2：不同分区中的 SWC。不同分区中的 SWC无法访问彼此的RAM区域，因此无法损坏彼此的内存内容。根据定义， SWC无法访问外围设备，因为它们不应了解底层微控制器架构。当 SWC被授予对外围设备的直接访问权限时，可能会创建可能不安全的系统。用例3：MCAL驱动程序MCAL驱动程序是函数的集合，例如读/写/初始化。它们必须由另一个实体执行，例如BSW或CDD。有关详细信息，请参见图8。MCAL驱动程序需要对相应外设硬件模块的外设空间进行读/写访问。根据硬件架构，可能还需要处理器的监控模式。2.1.3检测和响应功能安全机制内存分区通过限制对内存和内存映射硬件的访问来提供保护。在一个分区中执行的代码不能修改另一个分区的内存。内存分区可以保护只读内存段，以及保护内存映射硬件。此外，在用户模式下执行的SWC对CPU指令的访问受到限制，例如重新配置。内存分区机制可以在微控制器硬件（如内存保护单元或内存管理单元）的支持下实现。微控制器硬件必须由 OS进行适当配置，以便于检测和防止不正确的内存访问。然后监控在不受信的/用户模式内存分区中SWC的执行。如果内存访问违规或非受信任/用户模式分区中的CPU指令冲突，则错误访问将被阻止，微控制器硬件会引发异常。OS和RTE通过执行分区关闭或重新启动此分区的所有软件分区来消除错误的软件分区。注意：OS的实际响应可以通过保护挂钩实现进行配置。有关更多详细信息，请参阅 OS SWS[i]文档。注：AUTOSAR文档“应用程序级错误处理说明”[ii]提供了有关错误处理的其他信息。在文档中，解释了如何执行错误处理以及可以从何处获取所需数据（例如替代值）。此外，本文档还提供了有关如何在AUTOSAR中执行 OS-Applications/分区终止和重新启动的详细说明（用户手册）。2.1.4限制1. 具有相同ASIL分级的SWC的内存分区。ISO26262标准要求不同ASIL等级[iii]的 SWC之间的免干扰性。但是，标准不要求在具有相同ASIL等级的 SWC之间的免干扰性。允许使用由大量 SWC组成的 OS-Applications。如果单个 SWC导致冲突，从而导致关闭或重新启动整个内存分区，则此内存分区的所有其他正常工作的SWC也会受到影响。2. 内存分区不适用于受信任的 OS-Applications。受信任/监控模式内存分区的执行不受 OS和某些MMU/MPU硬件实现的控制。3. 任务级别不支持内存分区。任务级分区的实现对于AUTOSAR OS实现不是必需的。因此，可能不支持 OS-Applications中的免干扰性。4. 由于内存分区导致的性能损失。根据应用软件的架构以及微控制器硬件和 OS的实现，使用内存分区会降低性能。此损失随着每个时间单位执行的上下文切换数的增加而增加。5. 无基础软件分区。基础软件的当前规范未指定来自不同供应商的不同ASIL等级的基础 SWC的内存分区。文章来源：AUTOSAR document 2021转载于汽车电子与软件微信公众号

通过桥接网络进行的面向数据包的通信已经确立起了的世界性标准。然而，原来的以太网不是确定性的，不适合实时应用。改善以太网实时性的一个解决方案是AVB/TSN。以太网帧或IP包可以在不同的物理介质上透明地传输，因为以太网是与物理层解耦的。这意味着，通过不同网络类型连接的设备可以毫无问题地相互通信，例如，在汽车中使用无线连接的移动电话和使用INICnet网络（ISO21806）的控制单元（通过车辆的Telematic处理单元或网关）。IP数据包从发送方路由到接收方。但传输时间、延迟、抖动和丢失的数据包怎么办？最初的以太网不是确定性的，也就是说，无法控制设备何时和多少数据被允许发送，也无法控制数据包的传输路线。两个设备之间的传输时间不断变化，如果网络过载，数据包就会丢失。这种行为与必须保证低延迟的关键应用是不相容的。提供低延迟和确定性的专有总线和网络技术只是一个有限的解决方案。所有市场的趋势是走向标准化和开放的技术，不与特定的制造商相联系。此外，标准技术既不需要特殊的专业知识，也不需要复杂和昂贵的网关。 AVB解决方案 各界对以太网的弱点已经研究了很多年。随着时间的推移，已经开发了各种解决方案来改善以太网的实时性，其中之一是AVB/TSN。AVB（音视频桥接）的话题是在2008年的一个IEEE工作组中开始的。当时，目标是改善以太网上时间关键的音频和视频数据的传输，通过以太网提供时间关键的音频和视频数据。AVB不仅包括IEEE 802.1BA标准，还包括以下标准：- 用于时间同步的IEEE 802.1AS- 用于交换机中传输控制和帧的中间缓冲的IEEE 802.1Qav- 用于音频和视频流的动态带宽分配的IEEE 802.1Qat- IEEE 1722传输协议- 用于动态配置支持AVB的网络和设备的IEEE 1722.1该标准已于2011年完成并发布。它首先被用于各种多媒体应用，后来也被用于工业部门，特别是用于传输时间紧迫的命令或传感器数据。随着人们对非多媒体应用的AVB兴趣的增加，在IEEE成立了时间敏感网络（TSN）工作组。TSN继承了AVB的标准，并在专业音视频、工业、汽车和航空航天等领域涉及更广泛的应用。在汽车领域，最初的AVB标准至今仍在使用，但在某些情况下，TSN的修订版本已经在使用。本文主要涉及AVB标准，它相当于TSN。 用gPTP进行时间同步 通用精确时间协议（gPTP - IEEE 802.1AS）是所有支持AVB的系统的共同基础。其目的类似于计算机行业的网络时间协议（NTP）。NTP确保计算机时钟与一个参考时钟同步，精度为毫秒。这样的精度对于计算机和服务器来说是绝对够用的，但对于同步或时间紧迫的应用来说就太不准确了。gPTP在以太网设备中提供了更精确的时间基础，通常在微秒范围内，最好甚至是纳秒。时间从一个或多个时间参考节点（根据IEEE标准的gPTP主节点）分配给一个或多个客户（根据IEEE标准的gPTP从节点）。与IEEE 1588的两阶段程序类似，gPTP总是连续发送两个帧："SYNC "和 "Follow Up"。根据所包含的时间戳，客户机将其本地时钟重置为参考时间，这样网络中的所有设备就能以完全相同的时间为基础工作。然而，只有同时考虑到网络上所需的传输时间，才能实现非常准确的时间基础。为此，所谓的对等延迟测量总是在直接相邻节点之间成对进行的。然后，每个节点测量的传输时间的总和导致对等延迟值，通过该值修正gPTP时间。 传输协议 IEEE 1722-AVTP：音频视频传输协议是通过以太网AVB传输音频/视频数据以及时间关键型数据的标准传输协议。它是一个精简的ISO/OSI第二层协议，通过MAC地址对设备进行寻址。因此，没有必要集成一个完整的IP协议栈。这有助于最大限度地减少项目和设计的规模、成本和复杂性。IEEE 1733-RTP/RTCP：RTP和RTCP（IETF RFC 3550）是基于IP的网络协议，用于通过以太网传输音频和视频数据。它们已经在所有工业和消费设备中使用了多年，如视频监控摄像机或InterCom设备。IEEE 1733是对RTP/RTCP的改进，用于与AVB同步传输，因此是基于IP的IEEE 1722的替代品。 流量整形 一个以太网网络通常由大量的终端（计算机、电子设备）和桥接器（交换机、网关等）组成。与所选择的传输协议无关，数据被封装在以太网帧中，从发送方通过几个桥接（hop）到接收方。帧的传输方式是不确定的。路由内的网桥以更快或更慢的速度转发帧（存储转发、直通）。在网络拥堵的情况下，帧有时会被缓冲一定的时间。在最坏的情况下，它们甚至可能丢失。工业以及汽车系统需要低的、确定的延迟，最重要的是需要可靠的传输，没有帧丢失的风险。流量整形（IEEE 802.1Q--服务质量的一部分）被用于此目的。流量整形定义了网桥应如何根据优先级处理帧的策略。例如，有几个关于流量整形的标准，例如：- IEEE 802.1Qav, 时间敏感流的转发和排队增强（FQTSS），也常被称为基于信用的整形（CBS）- IEEE 802.1Qbv, 增强预定流量，通常也被称为时间感知整形（TAS）- IEEE 802.1Qch, 循环排队和转发- IEEE 802.1Qcr, 异步流量整形其中CBS和TAS主要应用于汽车领域。通过基于信用的整形，每个以太网设备收到一个信用，用于发送帧。只要信用仍然是正数，设备就可以继续传输。之后，它必须等待，直到信用被补充。这种策略能够有效地利用带宽。没有预先定义的时间槽。需要不定期发送数据的节点可以收集他们的信用并一次性用完。用CBS配置AVB网络是相对简单的。相比之下，时间感知整形TAS策略是基于时隙模型的。它不再基于要发送的数据量，而是基于传输的频率。节点不再被允许在任何长度的时间内发送，但它们被保证允许非常有规律地发送。因此，可以实现一个明显更低和更确定的延迟。然而，Qbv的缺点是网络带宽并不总是被有效利用。如果节点不使用他们的时间槽，这些槽以及带宽就会丢失。 与AVNU的互操作性 对于AVB的实施，系统架构师可以利用各种可用的组件。根据系统要求，可以实现AVB的不同子集。一方面，这对硬件组件是有帮助的，但另一方面，它可能会导致互操作性问题，因为不同供应商的设备不支持完全相同的AVB功能。由于IEEE标准有时会被工程师们做出不同的解释，这使得情况更加复杂。AVNU联盟，即所谓的以太网AVB功能和互操作性规范定义了汽车领域的AVB子集和相关参数的参考，这些参数应在每个设备中实现，以确保供应商之间的互操作性。具备AVB功能的设备可以由测试公司进行外部测试，或在内部用特殊的测试设备进行AVNU兼容性测试。 AVB实践应用 在实践中，支持AVB的网络由几个部分组成：交换机、PHY和节点。为了达到预期的性能，所有的交换机和节点都必须支持AVB。通过IEEE标准、AVNU和OpenAlliance规范，来自不同制造商的PHY和交换机等组件现在可以高度互操作。然而，在终端节点实现音视频桥接仍然是一项复杂而漫长的开发任务。系统通常是在SoC或高端微控制器的基础上开发的，其中必须集成大量的软件：实时操作系统、Autosar和AVB协议栈，这往往还需要许可。一种替代方案是使用特殊芯片的AVB节点。这是一种集成了AVB协议的智能以太网控制器。因此，AVB作为一个基于硬件的解决方案立即变得简便，不再需要软件开发。文章来源于SoftAuto ，作者XESW

一、问题来源故事要从主机厂的整车开发流程说起。目前国内各大主机厂基本沿用通用汽车的GVDP(Global Vehicle Development Process，整车开发流程)来定义自己的整车开发计划。GVDP作为汽车领域最广为人知的开发流程之一，贯穿了车型开发的整个生命周期。GVDP将整车开发归纳为五个阶段：架构阶段、战略阶段、概念阶段、开发阶段、产品及生产成熟阶段。而每个阶段又分别定义了相应的“里程碑”节点。“里程碑”意味着整车开发工作阶段性结束，同时意味着下一阶段的开始。“里程碑”往往也伴随着本阶段交付物的锁定及下阶段交付物的启动。主机厂DRE（Design Release Engineer）们的零件开发工作会严格按照GVDP定义的阶段及节点按部就班完成。整车项目经理和VSE（Vehicle System Engineer）们同样以此制定工作计划，在相应的整车阀点收集并审核DRE们提供的交付物，包括但不局限于样件、设计文档、台架整车测试结果、最终的量产件。至于工程管理系统架构，主要由BOM（Bill of Material，物料清单）、PDM(Product Data Management，产品数据管理)等子系统构成。在这些子系统中，一般会以零件的LOU(Line of Usage)信息作为整车零件的管理颗粒度，零件的硬件和软件序号和信息在PDM中均挂在该零件总成下。DRE牵头零件工程更改的过程中，同样会以这个零件总成号和相应的LOU向整车项目组提交更改方案和费用。在新四化的热潮尚未开始前，该管理模式有序保证了整车的顺利开发和量产。对于涉及软件的控制器或执行器，一般硬件供应商同为软件供应商，功能范围相对稳定因而软件代码量较少，硬件和软件可按GVDP的节点要求统一测试和交付。在G3（预试生产）阀点前即可锁定零件的状态，在SOP（Start of Production，正式生产）后继续迭代的可能性较小。然而近几年软件定义汽车的热潮涌动，伴随着网联、智驾功能的蓬勃发展，软件的开发和迭代日益复杂，交付逐步与硬件分离。整车的一些域控制器，比如常见的ADAS，在实际的开发过程中，会由多家供应商和主机厂一起协同开发。例如，硬件由A供应商提供，底层软件发包给B供应商，应用层软件定点至第三家供应商C。一些应用层的支持功能，例如FOTA，也会选择开发经验更丰富的供应商D，甚至于测试台架或者人力也会外包给供应商E协作完成。这样便会给控制器的开发和软件的集成和测试带来巨大的挑战，很多控制器无法在SOP前完成所有功能的开发和测试验收，不少功能和BUG需要在车辆下线后去迭代。这一软件版本发布的现状对原有的GVDP开发流程也带来了变化，流程中尚未定义对于控制器软件版本快速迭代的管理方案，也没有定义SOP后软件发版流程。对于当前整车分布式电子电气架构及过渡阶段的域架构，新开发的车型都将拥有几十个控制器，各供应商的能力参差不齐导致了开发周期大相径庭，各控制器断点时间的不一致导致了交付的整车版本碎片化严重，碎片化的整车版本严重不利于整车的功能测试和验证。二、解决方案为了解决上述问题，同时加强整车生命周期内软件开发的协同管理，保证整车状态可控、计划有序，整车软件新版本可以及时分步实施，不少主机厂尤其是新势力厂商都制定了整车基线管理。整车基线管理是把整车的控制器软件版本按照周期划分基线。在节点到达时，根据当前释放的各控制器软件版本捏合成基线，以此作为基准进行集成测试和兼容性测试。测试通过后，锁定并发布基线。基线管理流程可基于GVDP的流程，对于GVDP中定义的阀点，如EP、PPV、PP、P、SOP等，均可定义为整车基线节点，对网络诊断、整车功能的成熟度进行定义。随着整车SOP后的持续运营，基线计划可根据需求，根据FIP的持续迭代，定期更新发布。大致的运营流程如下图所示。车厂的基线小组需要在整车层面制定整车软件基线的需求、开发计划，并将计划输出给各控制器端，统一在某一节点交付当期基线的软件，并在测试验证通过后发布，通过OTA或者线下刷写的方式应用新版基线。三、遗留问题上文主要论述的是基线管理的需求来源和总体方案。随着OTA在各主机厂落地，极大改变了车辆软件迭代的方式。主机厂的整车基线管理势必与OTA的运营管理紧密相关，OTA的运营流程作为整车基线发布的下游，需要按着基线的节拍去实施。主机厂希望通过OTA迭代整车基线，并作为基线管理的主要手段。但对于目前尚不稳定的FOTA能力和流程的缺失，仍有如下问题待主机厂根据自己的实际情况解决：（1）对于多配置或者具有高低配零件的车型，整车基线的定义方式；（2）对于不具备FOTA能力或者FOTA失败风险较大的控制器，如何通过OTA+线下刷写的方式共同拉齐整车基线；（3）控制器售后换件或异常刷写导致整车基线异常的拉齐策略；（4）随着运营的深入，跨基线升级带来的开发和测试工作量。四、写在最后综上所述，对于OTA运营，随着整车基线管理的成熟，势必将由点到面，不再以控制器的颗粒度去运营，而将捏合成整车基线的控制器组，以整车功能的迭代计划作为基准，整体去迭代或者统一回滚，真正实现整车软件的生命周期管理。作者 | 18号线不到安研路转载于汽车电子与软件微信公众号

Build Start Project: lidar_slam, Type: Debug. /usr/bin/cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=/home/ww/MDC300F/MMC1/ADSFI_Sample/modules/lidar_slam/cmake/toolchain.cmake -DCMAKE_MAKE_PROGRAM=/usr/bin/make -DCMAKE_BUILD_TYPE=Debug /home/ww/MDC300F/MMC1/ADSFI_Sample/modules/lidar_slam Cannot run program "/usr/bin/cmake" (in directory "/home/ww/MDC300F/MMC1/ADSFI_Sample/modules/lidar_slam/build/cmake-build-debug-default_toolchain/gcc-linux-aarch64"): error=2, 没有那个文件或目录 Execute generation command failure. 

作者：田哲L4级自动驾驶公司走上研发L2级辅助驾驶的分叉路，是一条畅通无阻的大道吗？自2021年以来，部分以Robotaxi为目标的L4级自动驾驶公司开始分化新的业务，试图通过技术在商业收入方面有所突破。对于自动驾驶公司研发L2级辅助驾驶功能的现象，被部分人称为“降维打击”。在他们看来，L4级自动驾驶公司可凭借软件算法优势，为智能汽车提供更丰富的功能和驾驶体验，如同《三体》中高维度生物随手便可消灭低维生物及文明般轻松。不过，也有人对此不顾一屑。他们认为，以软件算法见长的自动驾驶公司进入强调软硬件结合的汽车功能研发领域，过程可能并不顺利。双方各执一词，难解难分。但可以肯定的是，自动驾驶公司跨入竞争愈发激烈的汽车供应链，可能为智能汽车发展贡献新的技术力量。L4级自动驾驶公司走上研发L2级辅助驾驶的分叉路，是一条畅通无阻的大道吗？危机下的选择不少人认为，商场如战场。在无休止的商业战争中，公司若能善用兵法，或能助其走出困境。这一情况，同样适用于部分困身于商业化迷雾之中的自动驾驶公司。它们急寻一招奇袭，助其冲破封锁。在思索中，它们看向L2级辅助驾驶系统。过去一段时间，部分L4级自动驾驶公司目光紧盯自动驾驶珠穆朗玛峰之巅的Robotaxi业务，以实现全无人Robotaxi商业化规模运营为己任，不惜任何成本向着峰顶攀登。几年时间的前行，它们离终点的距离逐渐缩短，目标却仍不在视线之内，资金的消耗却随着自动驾驶车辆规模扩大而增加。一个可以佐证的例子是，近期通用汽车发布的第二季度财报，透露旗下自动驾驶公司Cruise每天亏损超500万美元，亏损从同期的6亿美元增至9亿美元。Cruise自动驾驶车队与此同时，在规模商业化遥遥无期、经济遇冷的情况下，投资人的补给也逐渐减少。缺衣少粮的危机中，有的公司在路上因体力不支而倒下，有的则因缺氧和寒冷而元气大伤。此时它们的首要目标不再是抬头望天，而是活下去。幸运的是，中国汽车市场的变化，为自动驾驶公司提供了生存机会。一方面，中国智能汽车的迅速发展，需要融入自动驾驶技术。在特斯拉、小鹏汽车力推的智能辅助驾驶系统之下，量产汽车是否搭载高等级自动驾驶功能正有着成为产品的最大卖点之一的势头，为了避免技术落后，长城、吉利、大众、通用等主机厂纷纷成立自动驾驶部门，研发L2+及以上的自动驾驶功能。不过，研发自动驾驶系统是少数主机厂的可选项，目前更多的主机厂因条件有限而暂时作罢。为了后续产品尽快获得更多市场注意力，无论是否自研，向外寻求合作开发可量产的自动驾驶系统是一个不错选择。另一方面，在智能汽车市场快速发展的背景下，国内主机厂开始倾向于采取更灵活的合作方式，国外传统供应商的整套解决方案交付方式逐渐不符主机厂需求，这为国内供应商补位提供机会。此外，国外传统供应商此前大多将技术研发中心设在本国，这导致它们的技术难以满足快速变化的中国市场需求。高工智能汽车研究员监测数据显示，截至2022年一季度末，博世在中国乘用车前装标配市场份额由2021年的27.79%下滑至25.61%。国外传统供应商本土化相对不足，使得主机厂尝试与国内汽车供应商合作，并促成后者壮大，魔视智能、福瑞泰克等一批本土Tier 1快速成长。向内，L4级自动驾驶技术商业变现困难，需寻变通之道；向外，市场需求旺盛，强敌气势减弱。自动驾驶公司研发L2级辅助驾驶系统，似乎一切自然而然。更为重要的是，智能汽车的算力提升及传感器数量增多的同时，整体成本大幅度下降，为智能辅助驾驶系统的低成本量产应用提供条件。在生存危机中，L4级自动驾驶公司借势改道，找到了一条可能的求生之路。真的是降维打击吗？这条道路是否平缓，没人知道，也并不重要。重要的是，部分自动驾驶公司们知道，沿着这条道路前行似乎有着一线生机。真能如此吗？自动驾驶从业者王华（化名）对新智驾表示，L2-L3级系统的辅助驾驶系统，与L4-L5级全无人系统两者不存在必然的联系，辅助驾驶能升级成自动驾驶，但自动驾驶系统不能直接降维成辅助驾驶。如果双方不存在必然联系，L4级自动驾驶公司研发L2-L3级辅助驾驶系统，将面临哪些困难？技术难题是一道绕不过的坎。其一，自动驾驶公司乘用车量产经验相对不足。多位ADAS供应商人士对新智驾表示，大多数L4级自动驾驶公司对技术研发不计成本，并且通常使用大算力芯片，不太关注量产的技术路线。如果他们转做L2级辅助驾驶，可能“由奢入俭难”，比如在产品研发上会束手束脚。更重要的是，降维并不代表着算法可以复用，很多东西需要推倒重建。过去，自动驾驶公司将基于深度学习的软件算法作为护城河，比拼自动驾驶系统的稳定性与先进性，较少关注如何将自动驾驶系统前装于量产汽车内，从而导致自动驾驶公司对汽车制造认识不足。智己软件高级经理殷玮告诉新智驾，主机厂与自动驾驶公司合作也可以说是彼此互相学习。自动驾驶公司在处理整车产品时碰到的问题，会向主机厂学习如何解决；主机厂也会向自动驾驶公司学习不错的方法论，强化软件开发能力。其二，自动驾驶公司的部分场景数据积累相对不足。某自动驾驶供应商技术负责人告诉新智驾，低速场景及高速场景的自动驾驶在应用层有所区别。自动驾驶需要长期测试以收集数据进而迭代系统，低速场景和高速场景的不同，导致自动驾驶在两个不同场景下收集的数据不一样，最终两者的实践方式也有差异。过去，自动驾驶公司注重在高速场景下收集不同类型的数据，泛用性较广，而从辅助驾驶功能起步研发的公司更多注重低速场景。完全不同的场景，数据当然也完全不一样。因此，L4级自动驾驶公司研发低速场景的功能如自主泊车等，并不占据优势。其三，在算力大幅度减少的情况下开发自动驾驶系统，如同在螺蛳壳里做道场。不少自动驾驶公司过往宣传自动驾驶汽车反应灵敏时，时常提到其算力之高，上千甚至超2000Tops的算力似乎成为自动驾驶系统的标配，然而量产汽车出于成本考量，目前无法配置较高算力的芯片。对于习惯了在大算力条件下研发的自动驾驶公司来说，如何在极为有限的算力下完成L2/L3级自动驾驶系统开发是一个巨大的挑战，曾有人对新智驾将其形象地比喻为“由奢入俭难”。自动驾驶公司降维之路，道阻且长。自动驾驶公司的非技术难题如果自动驾驶公司解决了技术问题，辅助驾驶系统上车过程也不见得轻松。首先，自动驾驶公司需要实现将方案低成本可量产化。过去一段时间，部分自动驾驶公司以技术至上，试图通过各项多种类型的大量传感器打造尽可能可靠的感知系统实现自动驾驶，不过这导致自动驾驶解决方案的成本较高，不少公司发布的自动驾驶解决方案，成本高至数十万甚至上百万元，无法大规模应用。若自动驾驶公司试图降低整体成本应用于量产车型，需要考虑如何降低硬件成本的同时满足车规级要求，这对较少与硬件打交道的自动驾驶系统研发人员而言，着实不易。自动驾驶公司推出低成本的量产自动驾驶解决方案后，主机厂能否买单也是一个问题。“任何一家汽车公司不做自动驾驶，就是死”，上汽集团总裁王晓秋的一番话，体现着主机厂自主掌控自动驾驶技术的重要性。为了控制软件，国外主机厂如福特、丰田等较早收购自动驾驶公司，而大众则成立自动驾驶部门。殷玮向新智驾表示，智己汽车更倾向于自研以及同供应商开源合作。在域控制器及OTA越发能决定整车性能及驾驶体验的情况下，主机厂意识到智驾功能的研发，必须将自研与开源合作更好地在一个控制器内结合起来。这意味着，主机厂与外部的自动驾驶公司合作，自动驾驶公司可能不是交付整套自动驾驶解决方案，而是针对相关功能进行定制化联合开发。当自动驾驶公司与主机厂合作之后，能否如期交付产品也可能是一个问题。一位业内人士对新智驾表示，如果双方只是合作一两次的情况下，自动驾驶公司在较短的时间内为主机厂提供数百台定制化的自动驾驶汽车，产品功能很难让主机厂完全满意。他认为，一款真正成熟的产品需要双方长期配合，因为产品将具有自动驾驶技术、线控技术、新的软件技术，这些都需要长时间测绘、产品打磨才能完成。目前，虽然部分自动驾驶公司尝试与主机厂共同开发产品，但双方合作过程中必然会遇见不少问题，从而可能将产品交付时间延后。自动驾驶公司另寻商业化路径或许是降维，但这一过程并不轻松。变化，自动驾驶的新主题近年来，随着不少自动驾驶公司成功获得商业收入，关于自动驾驶行业即将进入淘汰赛的言论四起。一批自动驾驶公司已乘风而飞，另一批仍在原地迷茫。如果说，过去专注于某一场景是自动驾驶技术快速发展的秘诀，那么摆脱自我约束的边界，将技术以不同形式真正实践或许将是未来的新主题。L4级自动驾驶公司转向研发辅助驾驶功能，是初入汽车供应链的一股新力量，为中国汽车产业发展贡献着自己的力量。但不可否认，自动驾驶公司研发辅助驾驶之路刚起步，前方仍有不少困难。期待L4级自动驾驶公司在辅助驾驶功能的量产方面取得新的进展。责任编辑：未丽燕   来源： 雷锋网

　创金合信基金2022年投资策略会之主题赛道专场，于1月7日下午1点到2点30分举行，创金合信基金权益投研总部执行总监黄弢携手包括创金合信科技成长基金经理周志敏在内的九位行业主题基金经理，回顾2021年A股景气赛道、相对低迷的赛道和港股的市场表现及背后的原因，讨论2022年度行业层面可能的变化，相关的投资机会和风险在哪里？　　2022年1月7日下午1点到2点30分，创金合信基金2022年投资策略会主题赛道专场举行，图为创金合信科技成长基金经理周志敏。　　2021年是科技板块休整之年　　回顾2021年的科技板块，元宇宙是绕不开的话题，经过一轮轮的科普，普通投资者大多能部分理解这个新名词。谈及元宇宙的突然火爆，周志敏认为火爆体现在两个维度，一是以实业和资本为主的一级市场参与者积极投身其中，国外的互联网巨头、传统的计算机龙头、半导体龙头等都在为元宇宙站台，有直接改名从事这个行业，有要将当前日常办公相关的软件放到未来的元宇宙平台里，有要为元宇宙平台提供基础的硬件、芯片支持等；二是资本市场投资者的关注和追逐。在2021年初美股相关公司开始上涨之时，A股元宇宙板块开始跃跃欲试，到四季度集中爆发。　　至于元宇宙是一个炒作，还是有真正的需求，周志敏认为，一定程度上有部分概念炒作的成分，元宇宙的内涵在不断丰富，当一些新的内涵和应用被提出，如非常好的沉浸感、虚拟人应用等，暂时还没看到大规模的推开。但通过产业调研，他也了解到不少公司将之作为有真实需求支撑的产业在布局，因而元宇宙背后有真实的需求，只是说用现在产业的生态环境去满足需求，可能还需要一定的时间。　　回到科技板块2021年的总体表现，周志敏认为是科技板块的休整之年，虽然半导体板块在上半年的缺货涨价和下半年的新能源下游拉动的逻辑下各有表现，但前两年热度较高的5G板块陷入下游需求不热和上游供给受限的中期困境；消费电子在5G换机的增速高峰过后，受疫情影响整体出货量而走弱，同时还受到上游缺料涨价的冲击；以云、大数据为驱动的计算机公司也因为增速的放缓在消化前期的高估值。内忧之余，外部又有增速高企、前景广阔的新能源赛道吸引了市场的目光，因而科技板块的休整在意料之中。

从多方知情人士处获悉，百度智能驾驶事业群（IDG）的员工与资产今年已陆续由百度集团相关主体公司转入几家百度全资子公司。在今年一季度IDG全部转入新主体后，一些商业化部门需要制定并完成年度营收指标。这意味着被百度“养”了7年的IDG需要开始自己赚钱养家。今年9月，原负责百度B2B SaaS业务的集团副总裁储瑞松轮岗至IDG，任IDG智能汽车事业部总经理，全面负责智能汽车业务，向李震宇汇报。（腾讯新闻）

智能汽车时代的数字化转型，是最能体现当前我国汽车行业现实需要、最能体现整个行业对云与大数据等新ICT技术需求的一个抛面；同时，它也是整个汽车行业乃至ICT行业都不熟悉的一个全新的交叉领域。但毫无疑问，全球正在加速迈入智能汽车的时代。在这个新的时代中，对于整个行业以及众多的汽车企业来说，数字化意味着什么？如何才能实现成功的数字化转型？是所有人都必须面对的课题。作为中国成立最早也是最早研发智能汽车的车企——一汽也正在构思自己的数字化之路。智能汽车时代正在到来什么是智能汽车？智能汽车的标准又是什么？目前，全世界比较能达成共识的就是美国的SAE标准，用一种比较通俗的说法：所谓智能汽车指的是在车上要有两个可以开车的操作者，一个是人，另一个就是机器，如果只有人能操作车，这个车就不是智能汽车。能够操作汽车的机器要有3个最重要的功能：一是视觉与听觉，即环境感知，能代替人的眼睛、耳朵接受信号并认知周围的环境；二是路径规划与行为决策，能代替人的大脑规划行驶的路径、代替人的手脚进行转向和制动等操作；三是实时监控，能判断机器是否具备超越人为操作的极限能力。智能汽车在传统汽车技术基础上融合了人工智能、大数据、云计算等ICT技术，是智能硬件、软件深度融合与集成的创新载体，这也是美日欧等汽车强国积极研究、开发无人驾驶汽车的主要原因之一。驾驶是人类最大的乐趣之一，可以说每个人心中都有一个畅享自由驾驶的梦想，但与此同时，驾驶也给人们带来了不少灾难。以美国为例，多年的统计数据表明，高速公路每年因为交通事故导致的死亡人数都在20000人以上持续不下。虽然研究人员做出了许多努力，开发了包括安全带、ABS、儿童座椅等众多技术，但仍未能从根本上解决问题。经过多年研究，美国交通部认为，智能汽车及其机器驾驶员将有望彻底解决这一难题。因此，基于安全这一国家顶层需求是驱动汽车行业迈向智能汽车时代的另一大动因。而各国迈向智能汽车的路径则不尽相同。美国的特点是从国家标准上进行引导，然后由企业入市进行竞争，特别是鼓励像谷歌这样的高科技企业参与，以高科技优势带动智能汽车跨越式发展，以期占领智能汽车产业的世界领先地位。2015年，美国前总统奥巴马在一次讲演中曾表示，美国要利用自身在网络、大数据和人工智能等领域的优势，重新占领汽车行业的制高点，在智能汽车时代取得对欧、日的领先地位，所以，美国确定要在2020年率先迈入智能汽车时代。欧盟历来是汽车强企云集的地区，拥有奥迪、奔驰、宝马等众多知名汽车品牌，欧盟制定了非常详细和严谨的路线图，以企业和产品的智能化转型为主导，在传统汽车产品工程基础上实现连续型渐进式发展。所以，欧盟所有的车企都有自己的发展路线图，无论是在高速公路还是在城市环境等不同场景。日本的特点是从国家整体战略来推进，以企业为主体、行业协同分工为路径，实现抱团共进。日本内阁2013年就提出《创造世界领先IT国家宣言》，并启动了国家战略性创新创造项目（SIP）计划，自动驾驶项目是其发展的重点，提出了到2020年实现自动驾驶全球领跑并引领全球自动驾驶/V2X标准的战略目标。所以，今天整个汽车行业都在关注着行业云的发展和数字化的需求，这一切并非是毫无原因的，其背后都有一个强劲的需求在拉动，那就是汽车的智能化。智能汽车数字化的4个领域到2020年，全球将会迎来由SAE 3级智能汽车所掀起的浪潮，作为一家汽车企业，除了关心其将带来什么样的智能汽车整车产品，更关心这些智能汽车是如何打造的？以及其将对车企提出什么样的要求？其实对于车企来说，数字化转型也好，智能汽车也好，都需要其进一步去挖掘客户对于智能移动出行的未来愿景需求，客户需要的是提高出行效率、消除交通伤亡、解决交通拥堵、便捷省心停车，以及通过效率的提升获取更多的收益。这些需求最终会导向一种新的产品形态及其所需的生态，而这种生态就是数字化，新的产品需要更多的传感器、更多的处理器和更多的软件，这些都是数字化的集成载体，更特殊的是其还需要一个环境，其中部分在车内，也有一部分是在车外，但未来更多的会在云上，其会创造一种新的大数据环境。如果再深度挖掘一下，未来到底有哪些汽车数字化领域，可以将其归纳为4个最重要的方面：汽车+物联网。汽车从诞生的第一天起就是为了实现物与物的连接，“汽车+物联网”以及“汽车+互联网”的结果肯定能大大扩展汽车所连接的物的种类和范围，但关键的问题是：“汽车+物联网”还会带来一场变革，其将迫使车企转型，从原来的传统制造业企业转型成为一个服务型企业，从提供单纯的汽车产品变成提供一种服务。未来，如果一个车企不能通过服务为客户带来价值，那么这个企业就会被淘汰，而且未来越来越多的价值会向服务端转移，因此传统的汽车制造业需要向移动服务业转型才能生存。例如未来智慧城市场景下的智能汽车，其所需要的关键技术大都与ICT相关，包括近距离的组网、信息的传输以及传感器的融合等。汽车+人工智能。汽车向智能化发展，在3个最重要的领域需要与人工智能相结合。其一是与传感器融合，其二是对路径的学习与规划，其三是在大数据的判断中用AI实现数据分类和推送。目前，我国正在以中国工程院为先导打造人工智能2.0，这在政府工作报告中也有所体现。“汽车+人工智能”将成为未来智能汽车的标志，未来的技术路线初期将会采用车载AI为主、云AI为辅的形态，但随着AI的计算量越来越大，最终将向以云AI为主导的方向发展，当然这还要看未来云技术和通信技术的发展。例如环境感知，车辆要感知环境，要分辩环境中物体是人是车还是猫狗、路障，还要确定这些人和车的速度，其方向是相对还是相向，最后还要让机器学会深度的AI。这其中需要的计算量是非常巨大的。汽车+大数据。原来汽车是通过硬件来使客户获得感知的，而在未来，所有的客户感知将来自于硬件+软件，其中软件所带来的就是数字。这些数字将会从两个侧面成为新的产品：一个是数字的推送，可以使驾驶者与乘坐者直接感知；另一个则可以通过数字服务获得新的客户，从而改变当前车企高度依赖4S店的单一服务方式。最终，数据将成为商品，数据将演变为服务。例如未来的共享出行，其所需的关键技术都与大数据有关，包括大数据的采集、存储和分析。汽车+智能制造。对于智能制造而言，汽车可以说是最为重要也最具前景的行业。传统的汽车制造模式是串行的，从产品企划到工程设计、从试验到量产、从投入市场到售后服务，一环一环紧密相连。但由于企业云的出现，特别是在云的基础上出现了技术的众创、数字化设计、数字化验证，使得整个汽车从设计到最后推送给客户变成了一个并行工程，借助于像数字化设计平台、数字化制造平台、数字化服务平台等这些建立在汽车企业云上的虚拟平台，汽车制造过程中的各项工程可以并行开展，这样就大大提高了车企的效率，提升了其经济性。例如，当初红旗汽车在开发过程中为了达到欧洲五星级的碰撞安全水平，总共进行了42台物理车的碰撞实验和测试，而现在已经有了数字化虚拟碰撞技术，包括华为也展示过这种基于云平台的创新，就可以大大减少上述物理实验的次数，最终降低成本、提高效率。最后，可以用IT行业习惯的大数据方式总结、挖掘一下汽车数字化转型的关键词，其中最重要的包括：5G、V2X、云平台、人工智能、大数据、云计算这就是未来，这就是现在传统制造业所不具备的新的经济增长点和新的供给侧革命。一汽的数字化转型思考一汽现在规划的产品升级方向主要有3个：一是智能安全汽车，简单地说就是在高速公路上不会发生碰撞的汽车；二是能够应对、缓解大城市交通拥堵的智能移动汽车；三是智慧城市或特定区域内运行的智能共享汽车；此外，一汽还致力于打造一个基于大数据的云平台。过去，车企只关心车，而现在则不仅要关心路、关心环境，还要关心云，这对企业的研发能力是一个巨大的考验，需要研发人员掌握新的技术，例如环境感知、人工智能、决策控制等等，这些都是原来从事汽车研发的人所不熟悉的领域。举例来说，原来一家车企支持架构的基础是机械，从最底层的发动机、变速箱，到之上的一体化、发动机电控，再往上就是电动化和新能源，最上层则是人工智能；而未来，车企的支持结构将发生变化，在原来的机械架构上出现一个智能架构，其将包括新的核心平台，不再是原来的发动机、变速箱、制动和转向平台，而是智能传感器、智能软件、地图定位、传感器融合、AI以及超级计算等平台。这种架构对汽车来说是一种革命性的冲击，如果说前几年节能减排、新能源等所带来的冲击还属于汽车内部，那么这次冲击则大多来自于汽车外部，这也是为什么现在有越来越多的高科技公司正在进军智能汽车领域寻找新的机会。同样重要的还包括互联的架构。原来，每辆汽车都有自己的总线，但只是车辆内部的电子神经网络系统，其对于智能汽车而言是远远不够的。智能汽车还需要与外界、与云进行互联，所以要产生新的互联架构，甚至要对驾驶者进行感知，了解其健康状况、是否处于疲倦状态等。大多数交通事故都是由于驾驶者短时间分神造成的，未来的智能汽车可以通过感知驾驶者状况在第一时刻接管驾驶权，改变汽车的驾驶状态，从而保护驾驶者和车辆的安全，防止交通事故的发生。此外，还有一项非常重要的核心技术就是动态地图，而且基于这项技术还可以衍生出众多新的核心技术和服务。例如，现在所有的智能汽车公司包括谷歌在内都在试图打造新的基于地图的智能驾驶技术，但一幅固定的地图是无法满足需要的，如何使地图成为动态的、实时的，可以反映当前这一刻最真实的环境，对于智能汽车来说是最最重要的。因此，一汽提出了一种新的AllwayEye理念，其核心思想在于：每辆车都能感知环境，可以随时将其感知的环境上传到云，然后再通过云下传给所有的车辆。如果有两辆车发生碰撞，只要发现这场交通事故的第一辆车将其上传到云，后面的其他车辆就都可以感知到，从而采取后续智能规划措施避免发生连串碰撞，还可以规避因事故而导致的拥堵。当前，汽车行业正处于一个新时代转型的十字路口，每一家车企都面临着一系列新的挑战——众多新的核心技术如何选择？原有的研发模式如何创新？如何构建一个众创的架构应对越来越复杂的技术变革？任何一家车企恐怕都难以仅凭自身能力独自解决，这也是今天一汽来到这里参加华为生态大会的原因，我们将会讨论如何进一步地合作，特别是在共性技术和基础技术上的合作。所有人都在勾画智能汽车的未来，一汽秉持的理念是与来自各个行业的伙伴合作，共筑汽车数字化生态，携手迈入汽车智能化时代。华为关键解决方案一汽启明车联网平台：具备高可扩展性与高灵活度，可自由选择T-Box厂商与上层应用厂商。平台采用解耦的架构对上层应用提供标准的API接口，以屏蔽不同车型的数据和命令的差异，使得上层应用开发变得简单，不同厂商的T-BOX接入变得简单，新业务可以快速部署。一汽大众OpenStack开发测试云：采用Opensource KVM为核心，IT资源弹性伸缩扩展和自动发放，实现业务敏捷上线。能够同时兼容其他异构平台，实现对多平台和跨地域的分布式数据中心的管理与运维，建立跨地域的分布式容灾体系，极大地节省管理和运维成本。

wujianming_110117华为+长安研发芯片？长安蔚来更名“阿维塔科技”5月20日长安、华为和宁德时代合作造车的重要进展，阿维塔科技公司正式披露。而在整车制造之外，合作方（长安、华为）其实还瞄准了汽车用半导体的设计和开发。路透社报道，知情人士透露，华为正在扩大与重庆长安汽车的智能汽车合作伙伴关系，包括汽车用半导体的设计和开发。两位消息人士称，两家公司在去年11月公布了智能汽车合作计划，过去几个月一直在芯片方面非正式合作。另一位消息人士称，他们可能很快就会成立一家芯片开发合资企业。　　昨天长安汽车曾发布公告称，其控股子公司长安蔚来更名为阿维塔科技。更名后的阿维塔科技将完全市场化运作，独立经营，独立发展，与长安汽车、华为、宁德时代携手共创全球领先、自主可控的智能电动网联汽车平台（CHN），打造丰富的智能汽车产品系列，构建“人车家”智慧生活和智慧能源生态。此前信息显示，华为还在计划加快推进卖车的进度，消费者BG CEO以及新增智能汽车解决方案BU CEO余承东已在内部定下明年销售30万台的目标。这意味着，到2022年，华为卖车的销售目标，是特斯拉的两倍。阿维塔的英文名字Avatar，听起来就是智能与科技感并存。湖南国芯半导体科技有限公司（简称 国芯科技 ）于2018年10月注册成立，注册资金5亿元，位于湖南省株洲市田心高科园。国芯科技由功率半导体行业龙头企业——中车时代电气，联合上游单位中环股份和下游单位长安汽车、南方电网、格力电器等共8家单位以及湘投控股公司等社会资本共同出资成立，是集设计研发、检测、技术服务于一体的高新技术企业，主要开展新一代宽禁带SiC与GaN、超大功率IGCT、精细结构IGBT、功率IC、MOSFET等芯片设计与特色工艺共性技术研究开发。近日，长安蔚来新能源汽车科技有限公司已正式更名为阿维塔科技有限公司。而阿维塔科技则将实现完全市场化运作，包括独立经营、独立发展。并与长安汽车、华为、宁德时代共同研发智能电动网联汽车平台（CHN），构建人车家的智慧生活和智慧能源生态。而在阿维塔科技更名之后，整合大量资源的同时，各自发挥所长实现三方术业有专攻的融合。比如华为将发挥其ICT技术优势，联合构建研发、渠道、服务、生态等全价值链环节，为用户提供电动汽车更高智能化水平。而且据最新消息，华为正在扩大与长安汽车的合作伙伴关系，包括汽车用半导体的设计和开发，或将成立一家芯片开发合资企业。而宁德时代将为阿维塔科技提供动力电池和新能源解决方案服务商，共创安全便捷能源生态系统。长安汽车则将基于合作伙伴的三方优势，着力打造智能电动网联汽车平台（CHN），并推出更多智能化电动车型。除了长安蔚来的合资公司更名外，在目前全球汽车芯片面临短缺的情况下，华为与长安也将深化合作解决缺“芯”问题。如果消息属实的话，不仅可以实现长安系列车型的增产，也能造福更多车企。此外，有消息称，华为消费者业务以及CEO余承东已在内部定下明年销售30万台的目标。你们觉得这个目标“小”吗？需要和华为进行合作。目前华为在科技研发上面要比长安汽车有很强的实力，而且华为也是中国5G技术的领导者与研发者，在全世界的排名也是遥遥领先的。因此华为在科技领域就有非常好的技术优势和人才优势，虽然在汽车领域涉及的比较少，但是华为对于芯片的研发技术也非常厉害。而现在的汽车对芯片要求也越来越高，所以长安汽车想要保持自己在市场上面的优势，肯定要与华为进行合作。这样才能提高自己汽车核心竞争力，让自己的企业保持良好的发展势头。从目前全球芯片短缺的情况来看，国内汽车芯片还会处于长期短缺的状态。这就会导致很多生产厂商无法制造出先进的汽车，所以必须要搞国产化芯片，只有把芯片完全国产化之后才能突破这种封锁，让更多的生产企业生产出物美价廉的汽车。另一方面华为现在在科技研发上速度也是越来越快，不仅是5g技术保持着领先优势，而且其他技术也有非常好的研究进展。所以我认为长安需要和华为进行合作，生产出自己需要的芯片。这样不仅能够把最核心的技术掌握在自己手中，而且还能加强自己企业的护城河建设。5月21日消息，据报道，知情人士透露，华为正在扩大与重庆长安汽车的智能汽车合作伙伴关系，包括汽车用半导体的设计和开发。两位消息人士称，两家公司在去年11月公布了智能汽车合作计划，过去几个月一直在芯片方面非正式合作。另一位消息人士称，他们可能很快就会成立一家芯片开发合资企业。受此消息影响，长安汽车从水下暴力拉升逼近涨停。此外，在今年5月20日，长安汽车发布公告，重庆长安股份有限公司控股子公司长安蔚来正式更名为阿维塔科技。这也意味着长安、华为、宁德时代联手造车的承载公司便是阿维塔科技。根据公告，阿维塔科技将完全市场化运作，独立经营，独立发展，与长安汽车、华为、宁德时代携手共创全球领先、自主可控的智能电动网联汽车平台（CHN），打造丰富的智能汽车产品系列，构建“人车家”智慧生活和智慧能源生态。近日，有媒体报道称，长安汽车和华为正在进一步扩大智能汽车方面的合作，在汽车芯片方面开展进一步的研发与设计。然而，尽管知情人士言之凿凿地表示双方将组建一家合资公司专注于此，但对于这一说法，长安方面却和媒体表示该报道并不属实，而华为方则表示，对于公开合作方面的事宜，一切都还要以汽车厂商所公布的信息为准。尽管目前，对于合作研发芯片的问题上还存在着一些谜团，不过双方的合作则确实是正在进行时的状态。在今年的5月20日，长安蔚来更名为阿维塔科技有限公司，而长安汽车也将于华为、宁德时代携手展开合作，共同推出面向于未来的高端智能电动车。而目前，芯片危机正在席卷全球，而芯片也成为了各车企占据竞争优势的新高地，因而长安与华为的进一步合作也并非无可能，只是究竟是何时还是要等到双方一同公布。一个企业能够在市场上长久立足，不仅具有核心竞争力，而且还要有很好的防御措施。而现在芯片危机是每个生产汽车的企业都要面对的状况，但自己本身企业无法进行研制。所以必须要与高科技公司进行联合研究，这样才能让自己的企业不会受到芯片的阻挠，让国产芯片能够尽快落地。只有掌握芯片核心技术之后，企业核心竞争力才会上升。否则企业核心竞争力始终无法提升上去。

首款Huawei inside智能豪华纯电轿车北汽阿尔法S（华为HI版）4月17日晚在上海发布，采用华为快充技术，充电10分钟，续航197公里，其智能座舱搭载鸿蒙OS操作系统。 据了解，现场测试车辆的行驶情况较为平稳，在红绿灯启停、无保护左转、避让路口车辆、礼让行人、变道等情形下均能实现城区通勤无干预自动驾驶。 曝光的华为自动驾驶技术视频显示，在车内配备安全员的情况下，工作人员对车辆进行脱手脱脚自动驾驶测试。在自动驾驶期间，车辆在穿过行人、电动车及汽车来回穿行的拥挤马路期间，车辆的自动驾驶状态表现得十分科技智能。除了会自动侦探前方的行人车辆，并对车内发出警告提示音之外，中控屏上还会通过红色警示图像进行提示。 另外，在两边停满车辆的拥挤道路上，车辆还会自动躲避对方来车，方向盘的调整十分精准，会车同时，还能给右侧的非机动车和行人，预留出一定的通行空间，宛如一个老司机一般。  华为介绍，在城市通勤场景中，该车实现了覆盖城区、高速、停车场的全场景点到点通行。例如，可智能识别红绿灯并进行停靠或行驶；当车辆在无待转区的路口，能够与对向的直行和左转车流进行交互博弈，最终完成左转；无论直行、左转、避让、上下匝道还是无保护转向，阿尔法S华为HI版都能轻松应对。而且基于机器自我学习技术，ADS每时每刻都在自我学习、自我进化，越开越聪明，成为消费者的专属好司机。ADS高阶自动驾驶系统作为专为中国道路和交通环境设计、以用户驾乘体验为目标的全栈（Full Stack）自动驾驶系统，采用了以终为始的设计思路，全天候全场景赋予私家车每日通勤连续体验。有赖于华为在人工智能领域近十年的深耕，在自动驾驶算法领域超过五年的投入，ADS形成了超级全栈算法、超级数据湖、超级计算与传感器硬件这“铁人三项”的完美闭环。针对城市复杂场景额外优化，驱动系统更快速的迭代优化，ADS可通过OTA持续为用户提供激动人心的新特性和新体验。阿尔法S华为HI版的车机搭载了流畅的HarmonyOS操作系统，且配备高清大屏、利用1+8+N全场景互联技术，使得导航、视频、音乐和通话等业务能够在智能座舱和其他设备之间无缝流转，让驾乘变得更简单、更有趣、更享受。比如，当用户视频通话时，进入车内可快速完成从手机到座舱显示屏的无缝切换，让用户充分感受车联万物的便捷，时刻体验最新科技带来的乘驾乐趣。华为将动力域的领先技术赋能于阿尔法S华为HI版。针对新能源汽车“充电慢”的焦虑，华为基于30余年电力电子技术积累，提供业内独家AI闪充全栈动力域高压平台解决方案，10分钟最高可充197公里续航里程。只需一杯咖啡的时间，阿尔法S华为HI版便能充满能量。双电机智能四驱，百公里加速轻松跑入3秒级俱乐部，比肩超跑性能，极大提升用户的用车体验。在算法层面，华为智能汽车解决方案BU，ADS自动驾驶产品线总裁苏箐曾经说过这样一句话：华为如果计算机上干不过特斯拉，我觉得可以关门不用干了。我们可以从两个维度理解“干不过”这三个字。一方面华为在人工智能领域有将近10年的深耕，在自动驾驶算法领域超过五年的投入，并不是新玩家；另外一方面，ADS是算法倒推的开发逻辑，全栈能力很重要。苏箐解释称，ADS的开发逻辑是根据目标场景（中国城区）倒推系统方案，再根据系统方案（传感器+算法）的需求，倒推对算力的要求，然后开发相应的硬件，因此算力和ADS算法完美匹配。

qeqewqeq