上一篇《新的编译器挑战：针对ADAS应用程序进行了优化（一）》中讲到了如何编写可移植的并行程序，在这里再补充一些。
根据C11 / C ++ 11标准，不使用“原子”（或基于“原子”的其他障碍）来保护变量免受潜在并行访问的程序是无意义的。 因此，编译器可以在这里生成任何代码，尽管错误消息将是最有意义的输出。 不幸的是，通常不可能检测到所有程序段和具有不正确保护的并行访问的数据。 有时，保护不正确的程序不会产生任何编译错误，因此看起来操作正确，同时根据微妙的计时问题自动产生错误的结果。 这些错误通常只发生在很长的测试时间之后，不能再现，因为它们依赖于非常难以再现的系统内的相对执行时间和时间相关的干扰。
因此，使用C11 / C ++ 11编写正确的并行代码并不是非常简单，但是像这样的专家们写的那样，像EMB2和LAPACK这样的库可以使用的风险相对较小。 作为一个额外的优势，这些库由于其并行性和优化而确保了相对较大的速度增长。 反过来，自写并行代码有可能产生正确的并行代码，但只能稍微更快或甚至比功能等效的顺序代码更慢，这甚至更容易维护。 编写正确的，有效的并行代码，特别是对于微粒数据结构来说，仍然是一项艰巨的任务。
新的并行数据结构是新科学出版物的主题。 还需要新的编译器功能（ARM™，AURIX，RH850，NVIDIA等）和补充加速器（例如AURIX中的FFT，ARM和NVIDIA中的SIMD）的异构硬件架构。
下面从硬件加速器和ADAS应用的安全要求这两方面谈谈。
一、硬件加速器支持
内部函数是支持硬件加速器最直接的方法。这些结构可用于解决来自C / C ++的特殊硬件指令。在一个新的层面上，特别的高级语言（大部分类似于C）被提供，使设计人员能够有效地解决他们的硬件问题。虽然这些高级语言需要编译和优化，但它们与底层硬件的接近简化了整个过程（NVIDIA的OpenCL，NVIDIA的编译器，GTM的C，TASKING的编译器，TI的EVE扩展C）。作为最终选择，编译器可以自动检测可以由加速器有效执行的代码区域，以便自动生成适当的代码（SIMD，icc）。但是，这种全自动发现在大多数情况下是受限制的，因为没有为特定加速器明确地写入标准C / C ++代码。通常，次要代码修改会产生出色的结果，尽管适当的调整工具是必不可少的，以便以合理的开销来实现必要的更改。
此外，许多异构硬件架构要求每个可编程单元都使用自己的编译器进行寻址。 为了避免处理过多的不兼容的工具，这将产生新的安全隐患，建议使用可解决所有可编程单元并确保工具之间相互兼容的工具环境。 例如，AURIX的TASKING工具环境可用于从单个IDE编程和调试架构的所有单元。 由于符号信息在不同的单元之间兼容，所以可以更安全地控制和监视单元之间的相互作用。
二、ADAS应用的安全要求
为了满足ADAS应用程序的特殊安全要求，必须根据ISO 26262开发和鉴定与这些应用程序相关的工具（建模工具，编译器，分析工具）和软件组件（操作系统，库等）。一些 使用神经网络可以了解更新的安全要求（图4）。神经网络是常用于检测和处理ADAS应用中的传感器数据的软件组件。
图4 神经网络示意图
虽然有基于神经网络的有趣的原型，但仍然不清楚在极端情况下如何确保这些网络的正确行为。 目前，没有已知的程序可以保证神经网络总是正常运行，没有道路使用者的任何风险。 因此，如果没有合适的监督实体，则不能让神经网络进行安全关键决策。 除了用于神经网络本身的硬件之外，这将基于输入数据（例如，加速到100km / h，通过左侧，启动紧急停止等）发布难以预测的决策提案， 必须有一个运行在具有最高安全认证（ASIL-D）的硬件上的监督实体。
后者将使用可预测的算法来操作，以检查神经网络提出的提案是否可以安全执行，或者是否应选择更安全的替代方案（图5）。 例如，监督实体将检查神经网络提出的通过机动是否可以执行而没有任何风险。 为此，它将使用自己的可预测的计算来检查是否没有障碍物。可以在一些领域（例如数据融合）中仍在研究可预测的算法，以便创建有效的监督实体。 ADAS应用程序的许多可预测的算法都是基于LAPACK等人支持的线性代数计算。 优化的解决方案，包括TASKING中的LAPACK性能库可用于在各种目标平台上高效，安全地实现这些算法。
图5 神经网络和图像处理与监控实体安全处理相结合的高性能处理
ADAS应用程序的其余部分可以使用几种有助于满足各种ISO 26262要求的工具和过程进行认证。 可以高效地使用静态分析（Polyspace，Klocwork等）检测到简单的编程错误（包括未初始化的数据）。 为了检测安全相关的访问冲突（具有不同ASIL的访问对象并在内存保护单元 - MPU中创建保护故障的软件组件），使用TASKING编译器及其相关的安全检查工具支持是有益的。 编译器的集成安全检查器扩展可用于定义不同的安全类别（例如ASIL A至D），将项目中使用的数据和功能分配给不同的安全类别，并管理这些类别之间的访问权限。
此信息可用于两个目的。 首先，编译器无法执行某些优化（反向内联，代码压缩），因为如果在不考虑访问权限的情况下执行安全访问冲突，这些优化可能会导致安全访问冲突。 第二，相同的信息可以与TASKING安全检查器工具一起使用（如果需要，也可以为第三方编译器获取），以识别未检测到的访问冲突，这些访问违例将产生MPU异常，而无需任何额外的测试开销和高代码覆盖率。
为了对符合ISO 26262标准的工具（建模工具，编译器，静态分析，安全检查等）进行鉴定，大多数制造商提供了一个ISO工具包，大大简化了必要的过程。 在这种情况下，与在汽车领域拥有悠久记录的工具和制造商合作是有帮助的。ISO 26262-8为此目的使用“被证明使用”这个术语：假设长时间使用的工具很少出现问题，可能比新的工具容易出错。 除了解决上述安全风险外，编译器及其相关工具还有助于缓解与ADAS应用程序相关的设计风险。
选择硬件，库和开发工具的不合适组合在ADAS领域代表着重大的设计风险。 目前，几乎不可能预测特定ADAS应用程序的硬件和软件的特定组合的有效性。
例如，使用的硬件有太大和耗能的风险，或者太小。 不幸的是，今天没有连续的频谱可用：硬件转出太小无法通过尺寸略大的兼容硬件直接替代。 您可以选择具有较低安全认证级别的“非常大”的配置，或者具有较高认证级别的“显着更小”的配置。 两个选项之间的变化目前需要过多的开销，因为架构与其最佳使用所需的代码结构之间有显着的差异。
目前，编译器无法解决这个问题。 然而，编译器可以使风险得到管理如果它与合适的软件环境配对。 如果基于硬件特定的良好的建模解决方案，高效的线性代数库与满足ADAS应用程序典型要求的编译器环境相结合，最终的综合解决方案将不仅仅是其部分的总和。
通过使用建模解决方案，ADAS应用程序可以大部分以硬件无关的方式实现。 基础编译器和库使基于模型的通用实现能够以最小的开销和高效率移植到广泛使用的硬件平台上。 由此产生的轻微的缺陷可以通过精简来快速识别和消除。
对于通用代码，这种组合的解决方案将为各种目标平台上的最佳效率提供一个简短的，有前途的途径。 根据目标硬件和输入数据的分辨率，还可以使用一组额外的基准来记录所有工具的组合效能，这些数据可用于预测新的ADAS应用程序在新的目标硬件上的预期效率，而且相对较好 准确性。 这大大降低了选择不符合预期的ADAS应用程序的目标硬件的风险。
虽然TASKING编译器已经支持上述许多要求，但是今天的编译器都没有满足所有要求。 今天无法获得完整解决方案所需的一些工具和库。 因此，编译器的路线图很明确：必须解决剩余的要求，而不会忽视整个解决方案。 TASKING正在规划新产品，包括AURIX的认证LAPACK库，相信在不久的将来，肯定会改善。
上一篇《新的编译器挑战：针对ADAS应用程序进行了优化（一）》中讲到了如何编写可移植的并行程序，在这里再补充一些。
根据C11 / C ++ 11标准，不使用“原子”（或基于“原子”的其他障碍）来保护变量免受潜在并行访问的程序是无意义的。 因此，编译器可以在这里生成任何代码，尽管错误消息将是最有意义的输出。 不幸的是，通常不可能检测到所有程序段和具有不正确保护的并行访问的数据。 有时，保护不正确的程序不会产生任何编译错误，因此看起来操作正确，同时根据微妙的计时问题自动产生错误的结果。 这些错误通常只发生在很长的测试时间之后，不能再现，因为它们依赖于非常难以再现的系统内的相对执行时间和时间相关的干扰。
因此，使用C11 / C ++ 11编写正确的并行代码并不是非常简单，但是像这样的专家们写的那样，像EMB2和LAPACK这样的库可以使用的风险相对较小。 作为一个额外的优势，这些库由于其并行性和优化而确保了相对较大的速度增长。 反过来，自写并行代码有可能产生正确的并行代码，但只能稍微更快或甚至比功能等效的顺序代码更慢，这甚至更容易维护。 编写正确的，有效的并行代码，特别是对于微粒数据结构来说，仍然是一项艰巨的任务。
新的并行数据结构是新科学出版物的主题。 还需要新的编译器功能（ARM™，AURIX，RH850，NVIDIA等）和补充加速器（例如AURIX中的FFT，ARM和NVIDIA中的SIMD）的异构硬件架构。
下面从硬件加速器和ADAS应用的安全要求这两方面谈谈。
一、硬件加速器支持
内部函数是支持硬件加速器最直接的方法。这些结构可用于解决来自C / C ++的特殊硬件指令。在一个新的层面上，特别的高级语言（大部分类似于C）被提供，使设计人员能够有效地解决他们的硬件问题。虽然这些高级语言需要编译和优化，但它们与底层硬件的接近简化了整个过程（NVIDIA的OpenCL，NVIDIA的编译器，GTM的C，TASKING的编译器，TI的EVE扩展C）。作为最终选择，编译器可以自动检测可以由加速器有效执行的代码区域，以便自动生成适当的代码（SIMD，icc）。但是，这种全自动发现在大多数情况下是受限制的，因为没有为特定加速器明确地写入标准C / C ++代码。通常，次要代码修改会产生出色的结果，尽管适当的调整工具是必不可少的，以便以合理的开销来实现必要的更改。
此外，许多异构硬件架构要求每个可编程单元都使用自己的编译器进行寻址。 为了避免处理过多的不兼容的工具，这将产生新的安全隐患，建议使用可解决所有可编程单元并确保工具之间相互兼容的工具环境。 例如，AURIX的TASKING工具环境可用于从单个IDE编程和调试架构的所有单元。 由于符号信息在不同的单元之间兼容，所以可以更安全地控制和监视单元之间的相互作用。
二、ADAS应用的安全要求
为了满足ADAS应用程序的特殊安全要求，必须根据ISO 26262开发和鉴定与这些应用程序相关的工具（建模工具，编译器，分析工具）和软件组件（操作系统，库等）。一些 使用神经网络可以了解更新的安全要求（图4）。神经网络是常用于检测和处理ADAS应用中的传感器数据的软件组件。
图4 神经网络示意图
虽然有基于神经网络的有趣的原型，但仍然不清楚在极端情况下如何确保这些网络的正确行为。 目前，没有已知的程序可以保证神经网络总是正常运行，没有道路使用者的任何风险。 因此，如果没有合适的监督实体，则不能让神经网络进行安全关键决策。 除了用于神经网络本身的硬件之外，这将基于输入数据（例如，加速到100km / h，通过左侧，启动紧急停止等）发布难以预测的决策提案， 必须有一个运行在具有最高安全认证（ASIL-D）的硬件上的监督实体。
后者将使用可预测的算法来操作，以检查神经网络提出的提案是否可以安全执行，或者是否应选择更安全的替代方案（图5）。 例如，监督实体将检查神经网络提出的通过机动是否可以执行而没有任何风险。 为此，它将使用自己的可预测的计算来检查是否没有障碍物。可以在一些领域（例如数据融合）中仍在研究可预测的算法，以便创建有效的监督实体。 ADAS应用程序的许多可预测的算法都是基于LAPACK等人支持的线性代数计算。 优化的解决方案，包括TASKING中的LAPACK性能库可用于在各种目标平台上高效，安全地实现这些算法。
图5 神经网络和图像处理与监控实体安全处理相结合的高性能处理
ADAS应用程序的其余部分可以使用几种有助于满足各种ISO 26262要求的工具和过程进行认证。 可以高效地使用静态分析（Polyspace，Klocwork等）检测到简单的编程错误（包括未初始化的数据）。 为了检测安全相关的访问冲突（具有不同ASIL的访问对象并在内存保护单元 - MPU中创建保护故障的软件组件），使用TASKING编译器及其相关的安全检查工具支持是有益的。 编译器的集成安全检查器扩展可用于定义不同的安全类别（例如ASIL A至D），将项目中使用的数据和功能分配给不同的安全类别，并管理这些类别之间的访问权限。
此信息可用于两个目的。 首先，编译器无法执行某些优化（反向内联，代码压缩），因为如果在不考虑访问权限的情况下执行安全访问冲突，这些优化可能会导致安全访问冲突。 第二，相同的信息可以与TASKING安全检查器工具一起使用（如果需要，也可以为第三方编译器获取），以识别未检测到的访问冲突，这些访问违例将产生MPU异常，而无需任何额外的测试开销和高代码覆盖率。
为了对符合ISO 26262标准的工具（建模工具，编译器，静态分析，安全检查等）进行鉴定，大多数制造商提供了一个ISO工具包，大大简化了必要的过程。 在这种情况下，与在汽车领域拥有悠久记录的工具和制造商合作是有帮助的。ISO 26262-8为此目的使用“被证明使用”这个术语：假设长时间使用的工具很少出现问题，可能比新的工具容易出错。 除了解决上述安全风险外，编译器及其相关工具还有助于缓解与ADAS应用程序相关的设计风险。
选择硬件，库和开发工具的不合适组合在ADAS领域代表着重大的设计风险。 目前，几乎不可能预测特定ADAS应用程序的硬件和软件的特定组合的有效性。
例如，使用的硬件有太大和耗能的风险，或者太小。 不幸的是，今天没有连续的频谱可用：硬件转出太小无法通过尺寸略大的兼容硬件直接替代。 您可以选择具有较低安全认证级别的“非常大”的配置，或者具有较高认证级别的“显着更小”的配置。 两个选项之间的变化目前需要过多的开销，因为架构与其最佳使用所需的代码结构之间有显着的差异。
目前，编译器无法解决这个问题。 然而，编译器可以使风险得到管理如果它与合适的软件环境配对。 如果基于硬件特定的良好的建模解决方案，高效的线性代数库与满足ADAS应用程序典型要求的编译器环境相结合，最终的综合解决方案将不仅仅是其部分的总和。
通过使用建模解决方案，ADAS应用程序可以大部分以硬件无关的方式实现。 基础编译器和库使基于模型的通用实现能够以最小的开销和高效率移植到广泛使用的硬件平台上。 由此产生的轻微的缺陷可以通过精简来快速识别和消除。
对于通用代码，这种组合的解决方案将为各种目标平台上的最佳效率提供一个简短的，有前途的途径。 根据目标硬件和输入数据的分辨率，还可以使用一组额外的基准来记录所有工具的组合效能，这些数据可用于预测新的ADAS应用程序在新的目标硬件上的预期效率，而且相对较好 准确性。 这大大降低了选择不符合预期的ADAS应用程序的目标硬件的风险。
虽然TASKING编译器已经支持上述许多要求，但是今天的编译器都没有满足所有要求。 今天无法获得完整解决方案所需的一些工具和库。 因此，编译器的路线图很明确：必须解决剩余的要求，而不会忽视整个解决方案。 TASKING正在规划新产品，包括AURIX的认证LAPACK库，相信在不久的将来，肯定会改善。
举报
举报
