标签: ASPICE

简介 汽车行业在很大程度上依赖于先进的软件系统来确保汽车整车的安全性和功能性。为了满足消费者对可靠、安全的汽车产品日益增长的需求，两个至关重要的框架由此出现: Automotive SPICE(ASPICE) 和 ISO 26262。ASPICE 用于评估并改进汽车软件的开发流程，而 ISO 26262 则着重解决安全关键型系统的功能安全问题。本文探讨了这两个框架的互补性，并强调了它们的组合在综合提高汽车产品安全和质量上的重大潜力。 了解两者的互补性 Automotive SPICE 和 ISO 26262 框架并不冲突。相反，它们在汽车行业中着力实现不同但又紧密相关的目标。ASPICE 的首要重点在于评估和改进汽车供应商采用的软件开发流程，它致力于提高系统开发流程的成熟度和性能，使企业能够精准识别开发中需要改进的领域，并确保其符合行业标准。 而 ISO 26262 则专门针对功能安全，它为道路车辆中安全关键型E/E系统的开发提供了全面的指导意见和配套要求。ISO 26262标准涵盖安全关键型软件系统开发的各个方面，包括概念、设计、实施、集成和验证。 ASPICE 和 ISO 26262 重叠的优势 当ASPICE 和 ISO 26262 集成后，一个强大的框架由此而生。这个框架有利于促进整体开发流程，并能为汽车行业安全关键型系统的安全性和更高质量提供保障。一些关键的有益重叠领域包括: 流程成熟度和安全保证：软件开发符合 ASPICE 3 级标准是其流程成熟且定义明确的标志。通过将这一流程成熟度级别与 ISO 26262 标准相结合，企业可为安全保证和系统化开发奠定更为坚实的基础。这对于确保安全活动的规范性和严谨性，降低出错和发生危险的可能性十分必要。 流程校准： 符合 ASPICE 标准的开发流程可与 ISO 26262 所要求的特定安全相关活动和工作成果进行整合和统一布局。这种整合能够帮助建立一个简化并可控的开发流程，同时还能满足开发者对流程成熟度和开发安全性的要求。通过校准，新的开发流程确保了两种标准之下的流程要求在整个软件开发生命周期中均能得到有效的实施。 风险管理和安全： ASPICE 和 ISO 26262 都强调对风险的管控，但它们着重处理的风险类型并不相同。ASPICE 针对的是项目和流程风险，而 ISO 26262 则专注于与 E/E 系统故障造成的潜在危害相关的功能安全风险。通过将这些风险管理方法进行有益结合，企业可以有效地识别并降低流程和产品层面可能面临的风险挑战，从而获得更安全可靠的最终成果。 验证与确认(V&V策略)： ISO 26262 对安全验证与确认的流程提出了非常具体的要求，从而进一步丰富了 ASPICE 对这一过程及其基本实践的方法论。这些实践的结合更着重强调了贯穿整个软件开发过程的全面测试，审查和评估环节对确保最终成果满足功能安全要求的重要性，在这两个标准之下，特定的静态与动态测试都是验证活动中不可或缺的组成部分。 共通语言和相互理解： 同时使用 ASPICE 和 ISO 26262 可促进不同开发相关者对开发流程和安全要求的共通理解。这种共通语言有助于消除软件开发人员与功能安全专家之间的隔阂，促进彼此有效的合作与沟通，整个项目的效率得以有效提高。 行业认可度： 许多汽车厂商和供应商都希望其开发合作伙伴同时符合 ASPICE 和 ISO 26262 两大标准。通过同时应用这两个框架，供应商可以更清晰地强调他们对质量和安全的承诺，从而提高其声誉和竞争力，并更能满足客户的不同需求。 缩小差距，迎接挑战 由于 ASPICE 和 ISO 26262 的适用范围和目标有所不同，在典型的软件开发项目中进行整合可能会遇到一些挑战。为应对这些潜在挑战，企业可以遵循以下步骤： 制定综合战略： 企业应根据软件开发项目的具体需求和特点而制定的精准战略规划。清晰的战略路线图是确保两个框架和谐整合的基础前提。 注重员工培训： 为确保成功整合，企业开发人员应接受 ASPICE 和 ISO 26262 框架方面的教育培训，这将有效促进开发团队和安全专家之间的共通理解，提升合作效率。 使用适当工具和应用规则： 开发支持工具和方法论可以帮助企业有效管理开发的说明文件及开发过程中的协调与整合。利用适当的资源可简化整合过程，并确保两个框架不被违背。 定期评估审核： 定期的评估和审核有助于确定需要改进的领域，并确保现今企业的软件开发方向与 ASPICE 和 ISO 26262 的整合目标保持一致。然而，一个 ASPICE 评估方案并不足以涵盖以 ISO 26262 为标准进行功能安全评估的全部。 结论 总之，Automotive SPICE (ASPICE) 和 ISO 26262 两大框架的整合是汽车行业的重要方向。这两个标准对安全检测的侧重点不同，但目标一致。两者的结合可以通过解决开发过程和最终产品可能遇到的质量问题来提升汽车软件开发的质量和安全性。 由于符合 ISO 26262 标准的软件开发在很大程度上依赖于 ASPICE 所要求的过程能力和过程性能，因此将这两个标准结合起来并不会使开发的工作量增加。恰恰相反，ASPICE 为整合 ISO 26262 所要求的安全开发活动提供了一个合适的过程框架。 通过平衡有益整合和差异间的关系，企业或组织可以通过优化软件开发流程和功能安全来开发出更加可靠、更高质量的汽车产品。这对于在分布式环境中开发高度复杂的汽车软件来说尤为适用。 本文由MES模赛思工程师原创，欢迎扫描二维码加入公众号了解更多：

8 .23-24号，北汇信息于长春一汽解放、一汽红旗顺利举办了主题为“符合功能安全及 ASPICE 要求的软件测试”交流研讨会。本次研讨会主要聚焦于嵌入式软件代码、模型的静态、动态测试，受到了新能源、智能网联等部门的广泛关注，客户在现场与北汇信息的软件测试工程师进行了深入的技术探讨交流。 本次研讨会北汇信息主要从软件测试工具链出发，向大家介绍了功能安全及ASPICE规范对软件测试要求及在软件测试的各个阶段需要用到的测试工具，它们分别是模型静态检查工具MXAM，模型动态测试工具TPT，代码静态分析工具QAC及代码动态测试工具VectorCAST。此外，北汇信息也准备了工具实际操作演示的Demo和供体验工具的电脑，以期通过实际上手操作让客户深切感受到测试工具的测试效率和测试便捷性。 北汇信息的软件测试业务主要分为两个方面，软件测试工具链和软件测试服务。北汇信息的软件测试工具链包含了软件模型、代码的静态和动态测试阶段，无论是基于模型开发还是代码开发，该工具链都能完美覆盖。北汇信息的软件测试服务包含模型测试、代码测试，持续集成/持续测试等，测试经验广泛，无论是传统域控、新能源三电还是智能网联方向，我们都有强大的测试经验。北汇信息的软件测试团队主要分布在上海和北京，服务于全国客户。 后续我们也会持续在不同的城市举办软件测试相关的线下活动，如果您关注软件测试，对北汇信息的测试工具、测试服务感兴趣，欢迎关注北汇信息公众号，获取最新活动资讯。 北汇信息专注于汽车电子测试，基于OEM需求、行业标准规范以及自身测试经验积累，为客户提供测试规范开发、自动化测试系统和测试脚本实现及测试实施和问题分析全流程的交钥匙服务。目前，北汇信息长春办事处技术团队也在不断发展壮大，可为本地客户提供CAN、LIN、Ethernet、FlexRay各类总线网络诊断刷写测试、功能测试、智能网联测试、汽车新能源测试等服务。从测试工具、专用测试设备、完整测试方案到实车测试服务，我们与我们的客户一起努力，让中国的汽车变得越来越安全、越来越舒适、越来越智能。。

我们 将于 5 月 3 1 日 在北京市顺义区祥云小镇 附近 举办为期1天的“ 如何实施符合功能安全及ASPICE要求的模型动态测试 ”相关内容的交流探讨，诚邀各位新老客户朋友参加！ 背景介绍 随着汽车电子软件的复杂化，如何保证软件的开发质量，成为业内探讨的重要话题，因而出现了诸如功能安全、A SPICE 等相关业内公认的标准或者流程。这些标准、流程对于整个开发测试环节都有什么要求？如何通过TPT满足这些测试要求？如何实现针对M BD 开发模式下的模型 动态 测试？我们将会在本次Workshop和大家一起共同探讨，同时结合实践，让大家能掌握如何在TPT中实现满足功能安全、A SPICE 的测试开发工作。 德国 PikeTec 公司的TPT是嵌入式系统动态测试工具，其具备 独有的图形化建模方法，提供丰富的测试评估条件，生成高度可 定制 的测试报告， 自动化 完成整个测试流程 。TPT支持众多业内主流的工具平台和测试环境，可以覆盖 MiL - SiL -PiL- HiL - ViL 各测试阶段。 北汇信息 作为 PikeTec 的中国独家合作伙伴，多年 来 深入 研究和 应用TPT功能 ， 通过对国内 众多整 车厂和零部件企业的长期支持和服务 ，积累了 基于TPT的测试 和服务 经验，希望 通过本次 交流 与大家分享我们在 模型测试方面的实践经验。 本期亮点 功能安全及ASPICE对软件测试的要求及主流 软测工具链 介绍 基于TPT的实操 ， 教会 您 如何符合业内认证要求 关于TPT Workshop 语言 ： 中文 时间 ： 20 2 3 年 5 月 3 1 日 地点 ： 北京市顺义区 祥云小镇附近 规模及方式： Workshop采用小班制，我们将采用 理论+电脑实操演示的方式 与您进行分享 与交流 。 费用： 免费 活动日程安排 注意事项 报名 成功 人员 届时 请 自带电脑 报名方式 微信 报名 ： 请扫描下方 二维码填写 信息 报名 邮箱 报名： 请将以下 报名回执单填写完整发送至 marketing@polelink.com 并注明 “TPT Workshop报名” ，多人 参加请 分别分开填写 回执单。 电话 咨询： 010 -64782218-807 温馨提示 ： 请准确完整填写您的相关 信息 ， 我们将 在会前 3 日 通知 报名成功 的人员 。 确认 方式： 机会难得 ，名额有限 ，报名 前 2 0 位人员即可 参加，欲报从速！ 未能 参加本次 交流 的朋友也不要着急，我们后续会不定期 在 不同 城市 举办类似活动，如您有需 要 ， 也可根据您的需求进行定制化服务， 欢迎联系我们。 报名回执单 ： 姓名 公司名称 部门 科室 职位 手机号 邮箱 TPT 使用经验 无经验 小于1年 1-3年 3年以上 获取 信息 方式 销售 邀请 微信 公众号 其它 关注北汇信息 公众号，了解更多精彩！ 微信号 ： Polelink_Info

尊敬 的 女士/先生 ： 2019-2021 年我们在上海成功举办了T PT W orkshop，得到了广大技术朋友的支持和好评。 2022 年因为疫情原因我们未曾如期而遇，今年，春暖花开之际， 我们 将于3月2 3 日 在北汇信息 上海总部举办为期1天的“ 如何实施符合功能安全及ASPICE要求的模型动态测试 ”相关内容的交流探讨，诚邀各位新老客户朋友参加！ 背景介绍 随着汽车电子软件的复杂化，如何保证软件的开发质量，成为业内探讨的重要话题，因而出现了诸如功能安全、A SPICE 等相关业内公认的标准或者流程。这些标准、流程对于整个开发测试环节都有什么要求？如何通过TPT满足这些测试要求？如何实现针对M BD 开发模式下的模型 动态 测试？我们将会在本次Workshop和大家一起共同探讨，同时结合实践，让大家能掌握如何在TPT中实现满足功能安全、A SPICE 的测试开发工作。 德国 PikeTec 公司的TPT是嵌入式系统动态测试工具，其具备 独有的图形化建模方法，提供丰富的测试评估条件，生成高度可 定制 的测试报告， 自动化 完成整个测试流程 。TPT支持众多业内主流的工具平台和测试环境，可以覆盖 MiL - SiL -PiL- HiL - ViL 各测试阶段。 北汇信息 作为 PikeTec 的中国独家合作伙伴，多年 来 深入 研究和 应用TPT功能 ， 通过对国内 众多整 车厂和零部件企业的长期支持和服务 ，积累了 基于TPT的测试 和服务 经验，希望 通过本次 交流 与大家分享我们在 模型测试方面的实践经验。 本期亮点 1. 功能安全及ASPICE对软件测试的要求及主流 软测工具链 介绍 2. 基于TPT的实操 ， 教会 您 如何符合业内认证要求 关于TPT Workshop 语言 ： 中文 时间 ： 20 2 3 年 3 月 23 日， 9: 0 0-17: 3 0 地点 ： 北汇信息 上海总部 3 C 会议室 地址 ： 上海市 闵行区紫秀路 100号虹桥总部1号4栋3 C 规模及方式： Workshop采用小班制，我们将采用 理论+电脑实操演示的方式 与您进行分享 与交流 。 费用： 免费 活动日程安排 3 .2 3 TPT W orkshop 日程安排 交流 目标 结合功能安全 及ASPICE 要求，学习模型自动化测试实施过程 交流内容 1、 探讨符合功能安全及ASPICE要求的 软测 工具链 2、基于TPT的工具实操，高效实施模型动态测试 上午 9: 00-9 : 30 签到 9: 30-10 : 10 功能安全及ASPICE对软件测试的要求及主流 软测工具链 介绍 1 0 : 20-11:00 TPT 基础操作介绍(环境搭建、需求管理、用例编写及评估等 ) 1 1 : 10-12 : 00 测试用例自动生成及各种报告生成 下午 1 3 : 30-14 : 3 0 状态机测试用例的搭建 及评估( T rigger R ul e 及脚本评估 ) 1 4 : 4 0-15 : 30 AUTOSAR 平台应用方法介绍及 TPT 19 新特性介绍(预告 ) 1 5 : 40-16 : 40 TPT在测试项目中的应用技巧 （ 含车辆 模型演示） 1 6 : 40-17 : 30 Q&A 注意事项 报名 成功 人员 届时 请 自带电脑 报名方式 微信 报名 ： 请扫描上方 二维码填写 信息 报名 → 邮箱 报名： 请将以下 报名回执单填写完整发送至 marketing@polelink.com 并注明 “TPT Workshop报名” ，多人 参加请 分别分开填写 回执单。 电话 咨询： 010 -64782218-807 温馨提示 ： 请准确完整填写您的相关 信息 ， 我们将 在会前 3 日 通知 报名成功 的人员 。 确认 方式： 机会难得 ，名额有限 ，报名 前 2 0 位人员即可 参加，欲报从速！ 未能 参加本次 交流 的朋友也不要着急，我们后续会不定期 在 不同 城市 举办类似活动，如您有需 要 ， 也可根据您的需求进行定制化服务， 欢迎联系我们。 报名回执单 ： 姓名 ______________ 公司名称 _______________ 部门 科室 ______________ 职位 _______________ 手机号 ______________ 邮箱 _______________ TPT 使用经验 无经验 小于1年 1-3年 3年以上 获取 信息 方式 销售 邀请 微信 公众号 其它 关注北汇信息 公众号，了解更多精彩！ 微信号 ： Polelink_Info

在基础实践 2 中 您 如何定义验证标准 ? 有了基础实践 1 中定义的战略指导方针，您就可以进入下一步了。这个 BP （基础实践） 既适用于静态测试也适用于动态测试。预期的结果是单元的特定测试用例和单元级静态检查的定义。在本文中，我们将讨论基础实践 2-7 本文是 A SPICE 系列文章的第 3 篇 。 点击查看 A SPICE 系列往期内容 ： ASPICE系列：顺利通过ASPICE流程软件单元验证(SWE.4)-面包板社区 (eet-china.com) ASPICE系列：如何定义软件单元验证策略-面包板社区 (eet-china.com) A SPICE 基础实践 基础实践 2: 制定单元验证标准 ASPICE 过程期望定义标准，以确保单元执行软件详细设计和非功能需求中所描述的操作。 所有的工作产品都应该按照软件单元验证策略中的描述进行生产。 例如，应为静态测试定义以下标准 : 静态测量的类型 ( 例如， 圈复杂 度的测量 ) 和成功的评价标准 ( 测量的 圈复杂 度小于 50) 。 符合编码标准 ( 如 MISRA) 符合项目中商定的设计模式 非功能性的技术标准，例如资源消耗 (RAM/ROM) 您可以为所有单元设置单元验证标准，或者专门为 一类 单元或单个单元设置单元验证标准。为了不让工作失去控制，建议 对 一般定义 保持慎重和保守 。 专业提示 ： 覆盖目标 ( 例如代码覆盖 ) 通常不适合作为单元验证标准。它们最好用作测试结束标准，从而确定测试何时可以被认为完成。 对于每个测试规范， 基础实践 6 “ 确保一致性 ” 要求在测试规范和软件详细设计之间进行内容检查。在大多数情况下，这是通过审查等质量保证措施来完成的。此检查的目的是证明测试用例正确地测试了链接需求的内容。明确地期望每个评审都有文档记录。 如果在评估过程中发现缺少或不充分的非功能需求 ( SWE .1) 或缺少或不充分的软件详细设计 ( SWE .3) ， BP2 评估可能会被降级。 换句话说，如果前面的过程没有完成，他们也不会得到一个好的评价。 基本实践 3: 执行软件单元的静态验证 使用基础实践 2 中定义的标准，软件单元的静态验证应该在基础实践 3 中执行。 该验证可以通过以下方式执行： 自动静态代码分析工具 代码审查 ( 例如检查编码标准和指导方针的符合性或正确使用设计模式 ) 成功标准应该使用 BP2 的标准来确定。它们 具体说明 检查是成功还是失败。基础可以是覆盖标准或遵从最大值 (max . 圈复杂 度 最大为 Y) 或最小值 ( min . 每行代码最少 x 行注释 ) 。 基础实践 4: 测试软件单元 使用基础实践 2 中创建的测试规范，软件单元测试将在基础实践 4 中执行。预期测试将按照软件单元验证策略中所描述的方式执行。 对于基础实践 3 和基础实践 4 ，明确要求记录包括结果在内的所有测试。如果出现异常 现象 和 检验发现的情况 ，应将其记录、评估和报告。 此外， B P4 要求 以有意义的方式总结所有数据。在软件单元验证中，通常需要大量的测试数据。测试数据应该在多个详细级别上 为 手动和自动执行验证结果 而 准备。对此的解决方案是一个有意义的总结，例如 通过饼图的 形式聚集所有测试结果。 基础实践 3 和基础实践 4 的评估说明 与软件单元验证策略 (BP1) 相比，验证测试执行的偏差导致 BP3 或 BP4 的贬值。 对于 BP3 和 BP4 ，缺乏有意义的总结 会 导致降级。如果一个测试只被评为通过 / 失败，而没有关于测试的附加信息，那么评估人员对受影响的基础实践的评价不会比 “ Partly ” 更好。自动化软件单元测试报告中对单元的模拟和计算可以被视为对评估的充分补充信息。 评估人员将希望分别看到 BP3 和 BP4 的评估示例。具体地说，他们想要用它来验证一个发现是否符合软件单元验证策略和 SUP.9 问题解决管理。 基础实践 5: 建立双向追溯 在 A SPICE 中有几个地方需要双向追溯。如何实施取决于你自己。在这种情况下，您需要将详细设计的需求与测试用例和静态测试的结果联系起来。测试用例依次链接到详细设计的需求。 在最简单的情况下，这可以通过表格的形式完成 ( 列 = 测试用例 ; 行 = 需求 ) 。这种实现需要大量维护，而且很容易出错。 Pro-Tip: 为此使用 模型动态测试工具 TPT 等工具，尽可能容易地创建链接，最好是自动生成报告。您可以将此跟踪报告 为概述 用于一致性评审 (SWE.4 BP6) 作。在更改请求的情况下，您可以更快地分析 对 测试用例 的依赖性 。 评估人员明确地希望您将测试用例和需求双向地链接起来 (BP5) 。 基础实践 7: 总结和交流结果 所有 单元 验证 结果应汇总并通报相关方。 B P7 明确地期望有证据表明已经报告了结果。所有类型的通信媒体，如信件、邮件、视频、论坛帖子等，都可以作为证据 ( 只要它们有记录并可追溯 ) 。 如果 SWE.4 的 BP 3 和 / 或 BP 4 被评为 “ None ” 或 “ P artly ” ，那么预 计 评估员会对 BP7 降级。 在 BP7 的 ACQ.13 项目要求 过程 中，需要确定相关方及其对信息的需求。 ACQ.13 项目要求过程不作为 A SPICE 评估的一部分进行审查。然而，一个项目不应该仅仅因为过程没有被评估就忽略它，这是一个很好的实践。 总结 A SPICE 要求质量保证的许多活动和结果。许多所需的结果也应该以可验证的方式进行检查。 了解并应用这些评估规则可以增加获得良好评估的可能性。通常，一个项目在 2 年后达到 1 级，在 2 年后达到 2 级。 经验表明，当团队愿意学习并不断工作以满足需求时，成功是最快实现的。