全高级驾驶员感知系统和All Programmable SoC

道路安全从摩尔定律中受益良多，处理能力的提升以及 CMOS 图像传感器 (CIS) 和其他传感器技术的发展，让车辆制造商得以推出高级驾驶员感知系统 (ADAS)。ADAS 能增强驾驶员对周边环境的感知，减少发生碰撞的概率。部分系统还能够监控驾驶员并向驾驶员发出告警，例如在驾驶员打盹时。  

ADAS 还越来越多地接手控制（或为无人驾驶系统提供信息），从而为驾驶员提供泊车辅助、车道辅助和自适应巡航控制等功能方面的协助。 

 
显示导航和状态感知信息的 ADAS 抬头应用

因此，不出意料，到 2021 年预计 ADAS 市场的规模将达到 420 亿美元，目前的年复合增长率（GAGR）达到 10%（来源：http://www.marketsandmarkets.com ... ems-market-1201.htm)。

ADAS 通常使用嵌入式视觉、RADAR 和 LIDAR 等多类传感器来提取所需信息，并运用传感器融合方法整合来自多个传感器的信息。在嵌入式视觉领域， ADAS 又可划分为两大类。一类负责外部监控，解决车道偏离、对象检测、盲点检测和交通标识识别等问题。另一类负责内部系统监控，例如负责驾驶员打盹监测和眼睛检测等。内外部 ADAS 应用在实现图像处理算法时都面临自身的挑战。

这些挑战从实现应用所需算法的能力直至符合正确的汽车标准，不一而足。许多 ADAS 应用还要求传感器融合功能以整合来自多个传感器的输入，从而显著提高了所需的处理能力。在使用多个同类传感器的时候，传感器融合可以是同构传感器融合。在使用不同类型的传感器提取所需信息时，传感器融合则为异构传感器融合。 

因具备高度的灵活性，许多应用都选用 All Programmable SoC 或 FPGA 来实现系统。两种都能实现所需的算法，而且两者都能够连接不同类型的传感器类型和网络。 

伴随高性能 ADAS 应用而来的是几个系统难题。这些难题在开始思考时并不明显。汽车制造商需要满足严格的污染标准要求，因此总体解决方案的重量和功耗相当重要。因为生产的车辆以数十万计，解决方案的成本也很关键。虽然系统的保密性和安全性非常关键而且受多重标准的制约，使用 SoC 或 FPGA 能帮助我们解决一系列此类问题。

系统架构 

开发用于监测内外部摄像头的嵌入式视觉 ADAS 可以说这是一项更具挑战性的 ADAS 实现方案。该系统需要与车身四周多个摄像头连接，以处理图像并给乘客提供信息。许多摄像头解决方案使用点对点 LVDS 连线来传输数据，但是这会因布线需求而增加成本和重量。但是也有其他替代性方法正在日渐赢得使用，这些方法把部分功能内置在摄像头中。如果摄像头的图像输出采用压缩方式而不是原始图像，这样基于网络的架构就有可能实现传输。这些网络可以围绕通用汽车总线架构，例如： 

•    媒体导向系统传输 (MOST)——一种能以光学或电气物理层方式实现的高速网络。
•    IDB-1394——实现在电气物理层上的高速网络，采用雏菊链拓扑结构。 
•    以太网 AVB——以太网音视频桥接能够围绕车辆按需发送图像数据和其他数据

如果我们选择使用网络，系统架构师必须确保提供所需带宽，以便在摄像头和 ADAS 内核之间传输图像数据，同时满足应用时延要求。

ADAS 系统生成的数据可能需要与汽车中的其他系统共享，例如自适应巡航控制或泊车辅助。因此 ADAS 必须能够与 CAN 或 FlexRay 等其他通用汽车接口连接。 

 
Zynq 支持与传感器和消费者的任意接口 

在架构层，使用基于 All Programmable Zynq SoC 的方法可提供多重优势。如果点对点连线用于连接这些摄像头，摄像头接收器可实现在位于图像处理链条前的可编程逻辑中。如果要使用 All programmable SoC，处理器系统侧应具备足够高的灵活性，在需要与可编程逻辑中的逻辑和外部 PHY 结合时，能方便地采用 CAN、以太网和 FlexRay 等其他协议。双核处理器与可编程逻辑的完美组合可带来极低的单位像素功耗，因为系统紧密集成。 

All Programmable SoC 架构

SoC 体现出自己价值的地方是运用可编程逻辑 (PL) 实现摄像头接口和图像处理链。同时 SoC 的处理系统 (PS) 可根据需要提供通信、控制和额外的算法处理。图像处理流水线可使用所提供的众多 IP 库以及来自专业厂商的更专业的 IP 核来生成，以缩短产品上市时间。 

 
用于多摄像头系统的基于 Zynq 的架构模块

如果我们要开发额外的算法，我们可以运用Vivado HLS、SDSoC 和 Matlab 等高层次综合工具套件来加速开发进程。我们可以使用 C 或 C++ 等更高级语言，而不使用 VHDL 或 Verilog 等传统硬件描述语言来开发 IP，可加速产品上市进程。 

要进一步加快算法可使用 OpenCV 等开源框架。使用该框架开发的算法可映射到受 Vivado HLS 和 SDSoC 支持的 HLS 视频库中。这样可以顺利从概念和演示验证过渡到运行在目标硬件上进行特性描述和认证的算法。

许多已实现的架构会使用处理器的 DDR 内存作为帧缓存。例如如果使用基于以太网的系统或 PCIe，这样可以让处理器根据需要访问图像，进一步向前传输。我们还可以使用处理器系统的功能对存储在 DDR 中的图像执行额外的图像处理算法，然后在需要时再度插入到图像处理链条中。 

这样可以提供一个非常有意思的功能，即 SoC 本身可构成其自己的原型和演示平台。如果使用运行在处理器内核上的通用嵌入式视觉开发框架（如 OpenCV），这样可以提供一个精简的原型系统。该系统随即使用 SoC 的可编程逻辑可进行性能优化。

安全性

ADAS 的基本性质就是为汽车提供安全性，为此该系统必须和其他高可靠性系统一样在开发中遵循一个标准，对 ADAS 而言可适用的标准就是 ISO 26262。该标准定义了一系列汽车安全完整性等级 (A-SIL)，每个等级代表失效时间（以小时计）。总共有四个 A-SIL 等级，其中 D 是最高和最难达到的，A 是最低级别。要满足这些要求，需要使用综合工程交付生命周期来保障不仅能实现目标 A-SIL，而且生成的数据包通过存留必要的证据，还能证明这一点。

汽车应用受制于严苛的环境，为此开发人员需要确保自己使用的是汽车级的组件，例如通过 AEC-Q100 认证的组件。这类组件的制造和认证标准比商用组件要高。 

它们还必须考虑系统的安全性，防止无授权人员对系统进行修改，因为这可能导致灾难性的后果。 

使用 All Programmable SoC，就能够使用它的安全引导功能，防止未授权程序和比特流被配置到系统里。要做到这一点，开发人员可将 AES 加密、HMAC 和 RSA 认证与 TrustZone 技术结合使用。TrustZone 可让系统设计人员实现正交软件环境，限制访问含可编程逻辑外设在内的 SoC 内部硬件功能。

系统的健康状况可使用能够监测 SoC 供电电压和晶片温度的 XADC 加以监测。开发人员还可以使用外部 SoC 引脚来监测更广泛系统范围内的其他模拟信号，进一步监测系统的健康状况和使用情况。

因为该 SoC 将处理器和与内部 ADC 耦合的可编程逻辑紧密集成，设计人员能够得到因部件数量减少所带来的明显好处。而且减少组件数还能有力帮助我们实现所要求的低故障率。

总结 

从系统层面和器件层面来看，使用 All Programmable SoC 均能为ADAS开发带来一系列好处，实现更高集成度，减轻系统重量，提高系统能效。最新高层次综合工具能快速开发可供 OpenCV 等众多开源通用框架使用的图像处理功能。