tag 标签: QAC

相关帖子
相关博文
  • 2025-4-16 14:34
    43 次阅读|
    0 个评论
    ——摘自Perforce《2025年汽车软件开发年度报告》 随着人工智能在汽车软件设计和开发中的应用日益增加,各种问题也随之浮现,尤其是在相关法规和指导方针仍处于制定阶段的背景下。汽车软件团队面临着在快速变化的市场中保持竞争力的压力,因此必须在控制成本、确保安全性的同时按时交付高质量产品。 安全性,特别是"自动驾驶/半自动驾驶车辆中AI算法的安全决策能力",是人工智能车辆开发中最受关注的问题(49%)。遵循功能安全标准的开发团队在使用AI时需要额外考量,因为这类算法往往具有非确定性特征。值得欣慰的是,现有标准正在不断调整适应,同时诸如ISO/DPAS 8800《道路车辆-安全与人工智能》等新标准正在陆续出台。尽管目前已存在可应用于AI算法的技术手段,但要确保通过AI技术实现自动驾驶车辆的安全性仍任重道远。 安全性议题中,"避免因引入先进AI技术而产生的漏洞和网络攻击"位列受访者关注度第二位。集成人工智能等复杂技术的互联系统产生了更多攻击向量,这为恶意攻击者提供了可乘之机。与功能安全类似,现有众多安全标准和法规正在进行调整以适应AI技术的融合。 产品上市时间和开发成本在人工智能车辆开发的关注度中处于中间位置。一旦安全性和网络安全问题得到妥善解决,开发汽车AI软件的企业或将能更专注于提升行业竞争力这一维度。 值得注意的是,虽然质量是本报告中汽车开发的首要关注点,但"使用生成式AI时保持AI工具编写代码的高质量"却是受访者最不担忧的议题。这可能反映出受访者普遍认为AI有助于提升代码质量。 深度解析AI/ML在汽车软件开发中的应用 针对在汽车软件开发中应用AI/ML的受访者,我们特别调研了其在汽车开发不同重点领域的应用情况。大多数受访者将AI/ML应用于高级驾驶辅助系统(ADAS),但该比例较去年下降了26%。在车载信息娱乐系统(IVI)中应用AI/ML的比例同比增长了8%。此外,激光雷达(LiDAR)领域的AI/ML应用也实现了3%的增长。 新的汽车AI人工智能标准纳入安全考量 新近发布的ISO/DPAS 8800标准针对所有道路车辆功能安全领域的人工智能特有挑战提出了解决方案。 为何静态分析仍是汽车软件开发的关键支柱 根据调研反馈,汽车开发各领域的核心关切集中于质量、功能安全与网络安全。要有效缓解功能性代码质量与安全隐患,采用静态分析工具仍是最具实效的方法之一。 行业标准化静态分析工具——例如Perforce QAC与Perforce Klocwork——能够帮助开发团队实现以下关键目标: • 精准识别软件漏洞与薄弱环节 • 严格执行推荐的编码标准与开发规范 这两款Perforce静态分析工具不仅验证代码对各类标准规范的符合性,更能提供完整的合规性证据链。该能力可确保软件在功能安全和网络安全要求层面实现全面一致性、正确性与完备性。 通过部署静态分析工具,您可通过以下途径加速合规进程: • 强制实施编码标准并检测规则违反情况 • 在开发早期发现合规性问题 • 提升代码审查与人工测试效率 • 跨版本追踪并生成合规性报告 此外,Perforce静态分析工具全面支持MISRA准则合规,并已通过TÜV-SÜD认证,适用于包括ISO 26262 ASIL D级在内的安全关键系统开发。 亲身体验Perforce静态分析工具如何为您的汽车软件功能安全与网络安全保驾护航。立即联系北汇信息,申请免费试用。
  • 热度 5
    2024-10-10 14:46
    323 次阅读|
    0 个评论
    随着汽车软件开发的复杂程度不断提升,尤其是智能网联汽车和自动驾驶技术的进步,汽车软件开发的复杂程度不断攀升。为了满足日益增长的功能需求和技术挑战,异构硬件平台被越来越多地采用,不同的工具链也不可避免地被引入到实际的开发流程中。这一趋势不仅增加了开发过程的技术多样性,也使得单个项目的编译过程中会涉及到多种编译器。 本文主要讲解基于静态代码分析工具Helix QAC,我们该如何对多编译器工程进行静态分析。 新版本Helix QAC(2024.1+)的分析方式 为了适应这一趋势,Helix QAC在2024年发布的版本中引入了多CCT的功能。CCT(Compiler Compatibility Template),是Helix QAC软件中存储编译器环境配置的文件。根据CCT文件生成的方式,Helix QAC把CCT分为了两种: 自动CCT(Auto CCT):在工程同步时,自动生成的CCT; 静态CCT(Static CCT):基于CCT生产工具提前生成的CCT; 自动CCT 针对自动CCT方式,多编译器的配置也是自动的,无需我们进行额外的设置,目前Helix QAC支持使用自动CCT的编译器如下表: Compiler Filter Command ARM Clang qa_armclang armclang Clang C qa_clang clang,clang- ,clang- ,clang- ,clang- Clang C++ qa_clang clang++,clang++- ,clang++- ,clang++- ,clang++- Compiler caching tools ccache ccache,distcc,ccache-motorola,ccache_cc,ccache_cxx Embarcadero BCC qa_bccclang bcc64 GNU C qa_gnu gcc,cc,c++,gcc- ,gcc- ,gcc- ,gcc- GNU C Cross compilers qa_gnu *-*-gcc,*-*-*-gcc,*-*-*-gcc- * GNU C++ qa_gnu g++,g++- ,g++- ,g++- ,g++- GNU C++ Cross compilers qa_gnu *-*-g++,*-*-*-g++,*-*-*-g++- * GNU cc1/cc1plus qa_gnu_cc1 cc1,cc1plus Green Hills ARM qa_ghs cxarm,ccarm,cxarm64,ccarm64,cxthumb,ccthumb,cxtxarm,cctxarm Green Hills Integrity qa_ghs ccint*,cxint* Green Hills PPC qa_ghs cxppc,ccppc,cxtxppc,cctxppc Green Hills TriCore qa_ghs cctri,cxtri Green Hills v850 qa_ghs cx*850,cc*850,cxv850e,ccv850e Hexagon Clang qa_hexagonclang hexagon-clang,hexagon-clang++ HighTec Tricore qa_hightec tricore-c++,tricore-g++,tricore-gcc IAR compilers qa_icc icc* Keil ArmCC qa_armcc armcc Microchip MPLAB pic24 qa_microchip30 pic30-gcc Microchip MPLAB xc16 qa_microchip16 xc16-gcc Microchip MPLAB xc32 qa_microchip32 xc32-gcc,xc32-g++,xc32-c++ Microchip MPLAB xc8 qa_microchip8 xc8 Microchip MPLAB xc8-cc qa_microchip8cc xc8-cc QNX qa_qnx qcc,QCC,q++ Renesas qa_renesas ccrh,ccrl,ccrx,cx Renesas ca850 qa_renesas_ca850 ca850 Renesas cc78k0 qa_renesas_cc78k0 cc78k0,cc78k0r Synopsys DesignWare ARC qa_metaware ccac TI CCS qa_ti armcl,cl ?*,clpru TI CCS Clang qa_tiarmclang tiarmclang Tasking qa_tasking ctc,cptc,cmcs Visual Studio qa_mscompile cl,clarm,clsh Wind River qa_windriver dplus,dcc 静态CCT 如果我们采用传统的静态CCT的方式,那么需要我们提前为不同的编译器生成对应的CCT文件,并在HeliX QAC中将这些CCT导入到软件中。 Helix QAC现在支持为一种语言选择多个CCT配置,如下: 在我们完成源码加载后,如果不进行单独配置,那么Helix QAC会使用Default CCT对源码进行解析。如果文件夹内的源码使用的编译器与默认CCT不一样,可以在对应的文件属性中重新选择合适的CCT配置。 需要注意的是,我们只能针对文件夹进行CCT的选择,不能针对单个源码进行CCT的配置。而且,对于多CCT的工程,由于这是Helix QAC最新版本才有的功能,因此无法兼容Dashboard,只能将多CCT工程的分析结果上传到Validate中。 老版本Helix QAC的分析方式 由于老版本Helix QAC中无法为文件夹选择不同的CCT,如果要实现多编译器的工程分析,需要借助Helix QAC的CMA工程。 CMA(Cross-Module Analysis),是HeliX QAC提供的一种跨模块分析功能,它允许我们将多个HeliX QAC工程添加到CMA工程中,以进行跨模块的分析,并检查重复定义、不兼容的声明和未使用的变量等问题。 具体到多编译器的工程场景,我们需要为每个编译器建立一个Helix QAC工程,并将使用该编译器的源码及头文件加载到该工程中,然后将这些不同编译器的QAC工程添加到CMA工程中。 显然,Helix QAC的新功能提供了极大便利,来高效支持多编译器。 结语: 通过上述讨论可以看出,随着汽车软件开发复杂度的提升,异构硬件平台的应用已成为必然趋势。多编译器环境的引入不仅是技术发展的自然产物,更是解决日益增长的功能需求和技术挑战的有效途径。在此背景下,Helix QAC 作为一款先进的静态代码分析工具,其新版本中引入的多CCT功能为开发人员提供了强大的支持,该功能不仅简化了多编译器环境下的代码分析过程,还可以极大增强代码的质量和安全性。 如果想试用最新版的Helix QAC,欢迎垂询北汇信息。
  • 热度 3
    2024-5-15 10:35
    1264 次阅读|
    1 个评论
    带你走近MISRA C++:2023
    随着汽车工业迈入数字化转型的新纪元,软件的安全性与可靠性已跃升为设计和开发核心环节的重中之重。MISRA C++标准的诞生与演进,精准地回应了行业发展的需求。自MISRA C++标准首次面世以来,它便被奉为汽车软件工程师在开发实践中的圭臬。 MISRA C++的发展史 MISRA C++的起源可以追溯到MISRA C标准的成功制定和广泛应用。MISRA C是一套针对C语言的编码规范,首次发布于1998年,它迅速成为汽车行业中软件安全性和可靠性的标杆。(回顾MISRA C:2012介绍请见文章 《带你走近MISRA C:2012》 )随着C++在工业界的普及,尤其是在汽车电子控制系统中,对C++的类似规范的需求日益增长。基于MISRA C的成功经验和市场需求,MISRA组织随后发布了适用于C++03标准的编码规范MISRA C++:2008。这是首个针对C++语言的MISRA标准,包含一系列的规则和指导原则,这些规则覆盖了从编程实践到代码设计等多个方面,旨在帮助开发者编写出更加安全和可靠的代码。 MISRA C++:2008规范发布后,得到了业界的广泛认可和采纳。它不仅在汽车行业中得到了应用,还扩展到了航空、医疗设备和工业控制等多个领域,并对这些行业产生了深远的影响。随着C++语言标准的不断更新和新特性的引入,MISRA C++:2008也在经历不断的修订和更新,以保持与C++标准语言的同步,并覆盖新出现的语言特性。 MISRA C++:2008与AUTOSAR C++14 但随着后续新版本C++标准的发布,MISRA C++:2008并未将新的C++语言特性纳入,于是AUTOSAR组织发布了AUTOSAR C++14编码规范。 AUTOSAR C++14在制定时,大量借鉴了MISRA C++:2008的规则。MISRA C++:2008是基于C++03标准制定的,而AUTOSAR C++14则是基于更新的C++14标准。AUTOSAR C++14吸收了约91%的MISRA C++:2008规则,并对其进行了扩展和更新,引入了针对C++11/14特性的规范。 MISRA C++:2023 MISRA C++:2023发布于2023年10月,这是MISRA C++的最新版本。它为使用ISO/IEC 14882:2017定义的2017语言版本(C++:17) 开发的安全关键型软件的组织提供指导。 MISRA C++:2023规则分类 MISRA C++:2023整合了AUTOSAR C++14编码规范, 共179条准则。这些规则按照性质分为两类: Rule(规则)和Directive(指令),包含175条Rule和4条Directive。规则有三种不同类别:” Mandatory(强制)”、” Required(要求)”和“Advisory(建议)”, Mandatory类别的规则中包含5条Rule,Required规则中包含122条Rule和4条Directive,Advisory规则中包含48条Rule。 图1 MISRA C++:2023规则分类 图2 MISRA C++:2023规则类别 MISRA C++:2023还引入了MISRA C++的Rule可判定性分类。可判定性区分标准为是否能在任何情况下明确回答“该代码是否遵循了这条规则?”这个问题。 图3 Rule的可判定性分类 要注意的是,可判定性并不适用于Directive规则。 接下来让我们进一步了解MISRA C++:2023编码规范。 什么是 MISRA C++:2023 Rule 9.5.2,为什么它很重要? MISRA C++:2023 引入了 Rule 9.5.2:“ for 范围初始值设定项最多应包含一个函数调用” ,以避免在基于范围的 for 语句的 for 范围初始值设定项创建临时对象时可能发生的未定义行为。 为了理解为什么会发生这种情况,让我们仔细看看基于 C++ 范围的 for 循环。 什么是 C++ 中基于范围的 for 循环? 在编程中,循环用于重复代码块。当我们知道要在代码块中循环多少次时会使用for循环。C++ 基于范围的 for 循环是在 C++11 中引入的,作为容器迭代的简洁表示法。传统循环源自 C 语言,具有可选的循环初始化,然后是循环条件,最后是循环增量表达式。 传统for循环可用于迭代容器,如下所示: std::vector v = { "Example", "vector", "of", "strings" }; for ( auto &&i = v.begin(); i != v.end(); ++i ) { std::cout << *i << “ “; } std::cout << std::endl; 使用基于范围的for时,迭代器的使用是隐式的: for ( auto &&s: v ) { std::cout << s << “ “; } 对于同一循环,这是一个更简单的表示法。C++ 语言标准指出它是以下方面的缩写: { auto && __range = v; auto __begin = __range; auto __end = v.end(); for (; __begin != __end; ++__begin) { auto &&s = *__begin; std::cout << s << “ “; } } 但是,这种表示法存在一定的局限性。在上面的示例中, __range 是用 v 初始化的,这是一个更简单的变量,但也可以使用一个复杂的表达式,为其创建多个临时对象。 让我们考虑使用一个函数,该函数返回字符串的向量,并具有: 一个输出用空格分隔的字符串的循环,如上所述; 第二个循环,打印第一个字符串的字母,用空格分隔: std::vector createStrings() { return { "Example”, "vector", "of", "strings" }; } int main() { for ( auto w: createStrings() ) { std::cout << w << " "; } std::cout << std::endl; for ( auto c: createStrings() ) { std::cout << c << " "; } std::cout << std::endl; } 如果我们执行此操作,第一个循环将按预期运行,但第二个循环将调用未定义的行为 。 问题是 createStrings() 有两个函数调用。最里面的调用是 createStrings 的调用 ,最外面的调用是对索引运算符 的调用。 未定义行为的原因是 “ createStrings ”返回的临时对象 用作“ operator ”调用的参数,因此,根据 C++ 的规则,临时对象的生存期不会延长。 MISRA C++:2023 Rule 9.5.2 如何防范未定义的行为 MISRA C++:2023 Rule 9.5.2 旨在防止这种情况。 MISRA C++:2023 引入了规则 9.5.2,该规则要求for范围初始值设定项最多应包含一个函数调用。 它还建议通过在循环范围之前的单独声明中执行内部函数调用来解决此问题。例如: auto strings = createStrings(); for ( auto c: strings ) { std::cout << c << " "; } 现在,初始值设定项中只有一个函数调用,因此生存期扩展具有所需的效果,并且行为已完全定义。 请注意,此问题已在 C++23 中得到解决,其中初始值设定项的所有临时项的生存期已扩展到整个 for 语句。(原文请参考《 Avoiding Bugs in Range-Based For-Loops with MISRA C++:2023®》 ) 关注更多MISRA C++2023内容请见直播回放《汽车行业为何需要MISRA C++:2023》,本期课程我们联合了嵌入式静态分析领域公认的行业领导及先驱Perforce公司,并邀请到其合规总监Jill Britton女士探讨在这项汽车行业调查中的发现并介绍MISRA C++2023为何如此重要。 使用 Helix QAC 执行 MISRA C++:2023 规则 Perforce 的 Helix QAC 是一款静态分析工具,在提供 MISRA C 和 MISRA C++ 合规性检查以及许多其他有价值的分析功能方面处于领先地位。 Helix QAC 通过其标准合规性模块为 MISRA C++:2023 规则提供 100% 的强制执行覆盖率,现已推出。 作为Perforce公司的合作伙伴,北汇信息将为客户提供优质的静态代码测试工具和服务,欢迎您发邮件到marketing@polelink.com,申请Helix QAC免费试用。
  • 2024-3-18 17:25
    0 个评论
    Helix QAC—源码级静态自动化测试工具
    Helix QAC概述 Helix QAC 是一款源码级静态自动化测试工具,主要用于C/C++代码的完全自动化静态分析工作,提供一个高效、健壮和自动化的环境来引入和执行编码标准。Helix QAC根据尽早、更频繁测试的理念,在软件生命周期最早期软件开发阶段应用识别缺陷,提供与功能安全及信息安全密切相关的各类编码规范检测、代码质量度量、软件结构分析、测试结果管理等功能。 Helix QAC能够全面而准确地发现软件中潜在的问题,自身符合ISO26262功能安全标准认证。适用于自动驾驶领域,保障嵌入式软件的质量,提高其防御黑客攻击能力。 Helix QAC主要技术指标如下 · 提供基于行业标准的编程规则对代码进行检测 · 提供对软件的质量分析功能 · 提供对软件结构的分析 · 自动进行工程数据同步 · 提供丰富的CCT库(辅助工程快速配置) · 支持测试报告生成的选项配置,并可实现报告自定制 · 实现团队协作 · 功能安全手册支持静态项目通过各级ASIL(A-D)功能安全认证 Helix QAC产品方案 Helix QAC主要模块为QAC/QAC++(分析组件)、Dashboard(质量管理平台)、以及常用行业规则包(如MISRA C/C++、AUTOSAR C++、CERT C/C++、CWE C/C++等)。 除此之外,还可提供与各行业标准匹配的安全手册(如ISO 26262 Safety Manual等)。 Helix QAC主界面 · Helix QAC分析组件 · Dashboard平台 核心功能 · 多种类、覆盖面广的编程规则 Helix QAC提供与功能安全及信息安全密切相关的各类编码规范检测: Helix QAC对于各类编码规范的映射覆盖情况: 除此之外,Helix QAC还提供基于ISO C/C++标准制定出来的自定制规则集,可实现1900+ C语言问题、1400+ C++语言问题的检测,避免的风险包括但不限于:  未定义的行为  ISO语言约束违反  越界及溢出 (包括除零)  未初始化的数据  内存/指针运算问题(包括空指针引用)  危险的语言使用  不可移植的语言使用  控制流问题  类型转换  冗余代码  移位运算  对象/函数的声明定义问题  标识符的命名规范  违反最佳实践 · 自动对编程规则进行检查 在工具中添加要分析的文件,配置好完相应环境,运行一次就可以对添加的文件进行全部的分析,运行速度快,使用过程非常简单,容易理解,上手很快。 · 非常友好的帮助系统 分析结果内检查错误的时候,如果对所提示的内容不理解,可以双击这个错误,进入帮助系统。帮助系统除了提供了对错误的描述外,大多情况下都提供了例子程序,可以帮助理解错误的原因,并辅助开展代码修正。 · 提供对软件结构的分析 可以分析软件的结构,包括文件之间的包含关系、函数之间的调用关系以及函数自身的结构。 · 提供对软件的质量分析 采用国际标准的软件质量度量方法及度量指标,对客户的代码质量进行评估。提供六十余个指标进行评估,可以方便的在各个指标之间进行切换。 另外,也可以通过警告方式直观显示超阈值门限的指标,并可实时追踪至代码位置。 · 自定制报告 可实现固定模板报告生成,同时也可根据用户需求定制报告内容。可支持导出PDF报告、HTML报告。 · 团队协作 可实现版本管理、基线管理、用户管理、插入注释功能,实现团队协作。 · 可持续集成 支持命令行形式执行分析,能够实现与持续集成环境(如Jenkins等)进行集成。 资质认证证书 应用案例 经纬恒润 可提供服务项 经纬恒润官方账号,了解更多:请拨打010-64840808或发送邮件至 market_dept@hirain.com。联系时请说明,信息来源于面包板社区。
  • 热度 15
    2023-2-7 09:49
    1234 次阅读|
    0 个评论
    Helix QAC 2022.4 中的新增功能 Helix QAC 2022.4 为 MISRA C:2012 AMD3 提供了 100% 的规则覆盖,数据流被拆分为一个新的组件,提供了改进的分析性能,并升级了对 C++20 和 C23 的语言支持。 此外,此版本还包括改进的编译器支持以及各种 Helix QAC 组件的总体使用质量改进。 数据流组件 在 2022.4 中,数据流已从 QAC/QAC++ 引擎分离到自己的组件中。此更改提供: 1. 改进了大型项目的数据流分析性能。 2. 编译单元间分析 (Inter-TU) 在数据流中内化,不再需要两次分析传递。 3. 头文件中定义的函数每个项目分析一次。 4. 数据流诊断是针对 “ 数据流 ” 组件而不是 “qac” 或 “qacpp” 报告的。 5. 数据流是分析工具链中的一个单独组件,具有自己的配置选项。 编码标准覆盖范围( MISRA C : 2012 AMD3 , TS 17961 C 安全) 新的 MISRA C : 2012 修正案 3 合规模块,具有 100% 的规则覆盖率 1. 针对 C 编程语言强制实施汽车行业软件可靠性协会 ( MISRA ) 软件开发指南。这些指南旨在促进嵌入式系统环境中的代码功能安全性、信息安全性、可移植性和可靠性。 2. 与新的 C11/C18 功能相关的其他规则。 C++20 语言支持 此版本改进了与 C++20 语言功能用法的兼容性,包括在 C++20 模式下处理 GCC 头文件。 C23 语言支持 此版本增加了对以下各项的 C23 语言功能支持: 放宽对变量参数列表的要求。 改进的编译过程监控 此版本改进了使用 “qainject” 自动生成的 CCT ,这简化了编译理解和编译器设置;并且手册中提供了额外的指导,用于创建自定义过滤器,以基于支持的编译器(例如基于 GNU 的编译器)创建新编译器。 提高使用质量 CLI --添加了查看自基线以来的诊断功能( qacli 视图)。 --按抑制类型( qacliview --suppression-filter )进行过滤诊断。 --以多种格式输出 CMA 诊断: NONE, MULTIPLE, SINGLE ( qacli view --multi-homed-format )。 --使用户能够升级现有项目以与单独的数据流组件兼容( qacli admin --upgrade )。 GUI 数据流组件支持。 Dashboard 数据流组件支持。 Microsoft Visual Studio 2022 IDE 插件 支持使用 VS 2022 扩展安装多个 Helix QAC 。 Helix QAC 2022.4 的重要变化 预公告 CCT Generator 将于 2023 年报废 Helix QAC 2023.1 将不再支持传统的独立 CCT Generator 。 Helix QAC 2021.3 中引入的 “qainject” 工具将取代当前的 CCT Generator 。因此,使用旧版工具生成的 CCT 将被弃用且不再受支持。 从 QAC 软件包中删除不受支持的静态 CCT 随着使用 “qainject” 自动生成 CCT 的各种编译器的改进构建监控,到 2023.1 将删除以前包含在 Helix QAC 包中的大多数静态 CCT 。与使用静态默认 CCT 相比,自动生成的 CCT 有望提供更准确的分析结果。其目的是删除除 GNU gcc 、 Visual Studio 和通用编译器之外的所有 CCT 。