1. 目的
在系统或其软件要素，硬件要素开发过程中利用的软件工具，须要具备软件工具有用达到以下目的的置信度：
– 在开发产品中，将因软件工具功能异常导致错误输出的系统性故障的风险减小到最低；
2. 步骤
软件工具的评估与鉴定运动应当在项目初期完成，至少在开发阶段之前，以免影响后续开发运动输出物的有用性，延长项目进度。
分为3步：
2.1 软件工具利用操持
包括：
– 软件工具的识别码和版本号；
– 软件工具的配置
– 软件工具的利用案例；
– 软件工具的执行情况；
– 当软件工具功能异常并产生相应的错误输出时，会直接违背分配给相关项或要素的全部安全要求的最高ASIL品级；
2.2 软件工具评估
Tool Impact工具影响
特定软件工具功能异常可引入或不能探测开发中安全相关项或要素中的错误的大概性；
- 当有证据表明没有这样的大概性的时间，选TI1；
- 其他情况，TI2 ；
原文解释：软件工具不大概引入功能安全异常，或软件工具不大概出现无法探测与安全相关错误的情况，此时应当选择TI1，否则选择TI2。
示例：功能安全项目中应用到的软件工具有Allegro、Proteus、Visio等
- 此中Visio属于TI1品级，由于当Visio工具出现异常时，仅会影响到项目中各类图示信息，并不违背安全要求
- Allegro、Proteus属于TI2品级，当软件工具出现异常时，有大概直接导致安全要求的违背，例如产品电路的设计异常、不正确的仿真效果效果未被指出等
Tool error Detection 工具错误探测
用于防止软件工具功能异常并产生相应错误输出的步伐的置信度，或用于探测软件工具存在功能异常并已产生相应错误输出的步伐的置信度
- 当对预防或探测出功能异常及其相应错误输出具有高置信度时，选TD1；
- 当对预防或探测出功能异常及其相应错误输出具有中置信度时，选TD2；
- 其他情况，TD3
原文解释：利用了某些步伐来预防软件工具的失效或错误输出（例犹如范例软件工具输出效果对比等），或利用某些步伐探测该软件工具是否正常实现功能（例如用已知的输入输出数据集合来验证软件工具工作状态等）。
示例：功能安全项目中应用到的软件工具有C++、MS Project、EXCEL等
- 此中MS Project属于TD1品级，由于当MS Project工具的利用过程中是多人审视与抄送的，即使出现异常也会有多环节的验证审批过程，表现了软件工具的高置信度。
- C++属于TD2品级，当软件工具出现异常时，仅依赖软件工程师对编码效果核查，置信度略低
- EXCEL属于TD3品级，在植入公式的表格中对各项数据进行运算，没有相应预防步伐
评估流程
2.3 软件工具鉴定
对于TCL3的软件工具，利用方法：
对于TCL2的软件工具，利用方法：
1a. 从利用中增长置信度：
仅当具备以下方面的证据时，可以以为在利用中增长了置信度：
- 此前，已经将该软件工具用于相同的目的，具有相似的利用案例，相似的预定运行情况，相似的功能约束；
- 足够且充分的数据支持；（如可以获得利用时间长度，利用时间频率数据）
- 软件工具的规范定义未发生改变
- 在之前开发中获得的软件工具功能异常和相应错误输出的发生案例是以系统化方式累计
示例：
利用中积聚置信度
某软件工具的作用是芯片RTL逻辑验证，在项目开发过程中均会利用到此软件工具。此时企业内部数据中有对RTL代码编辑异常的记录程序，在这个记录单中会具体形貌RTL由于什么因素导致编辑异常。此时，可以筛选出由于验证导致的异常，判断是否是工具引起照旧人员操纵失误导致。最终工具引起的异常数占全部RTL编辑使命总数的占比就可以得出工具置信度的数据。
1b. 工具开发流程评估
- 用于软件工具开发的流程应满意适当的尺度。
- 应基于适当的国内或国际尺度对软件工具开发流程进行评估,同时提供适当的软件开发流程被应用的证据。
例如，ASPICE或者CMMI的认证
1c. 软件工具确认
软件工具的确认应满意以下准则:
- 确认步伐应提供软件工具符合分类中指定用途的特定要求的证据;
- 应对确认中发生的软件工具功能异常及其相应错误输出、其大概的后果信息以及避免或探测它们的步伐进行分析;
- 应检查软件工具对异常运行条件的响应。
以上策略可以以为是方法一，其缺点是：
- 只实用于特定的软件工具及其版本和情况
- 工具鉴定通常会导致很高的工作量,特殊是在频仍更改工具或其版本的情况下(例如,在更新、补丁等情况下),由于工具须要为每个新版本重新鉴定。重新鉴定也实用于大概对工具输出产生影响的工具情况的变化(例如,操纵系统或常用的软件库)。
方法二：
工具鉴定的另一种选择是**通过在利用软件工具的产品开发过程中引入额外的步伐来增长检测错误工具输出的大概性。这将把工具错误探测品级降低到TD1。**在这种情况下,流程如下：
- 这个替代方案不须要对特定的软件工具进行鉴定(第二步),而只基于工具的用例,并且可以独立于特定的工具、工具版本和其情况来执行。
- 这种方法大概导致更多的初始和正在进行的开发工作,由于须要引入额外的步伐来增长工具错误探测(例如,检查工具输出、额外的测试步骤、利用后续工具进行检查等)。然而,这通常可以减少工具鉴定工作,由于后续的鉴定步骤可以省略,在理想情况下,这个程序只一次就完成。
- 只要用例保持稳定,工具置信度水平就是有用的。对于额外的用例,第一步中的品级需被更新(影响分析),这大概导致须要进一步的步伐来增长工具错误探测。
3. 举例
例子：某款TASKING工具提供的证据：
为了满意置信度TCL2和TCL3品级的工具鉴定要求，TASKING 实际上采用了2种鉴定方法，“工具开发流程评估”和“软件工具确认”。
3.1 工具开发流程
软件工具的开发流程方面，比力盛行的有ASPICE和CMMI。ASPICE是“Automotive Software Process Improvement and Capability ”的缩写，顾名思义，这是一套用于改进汽车行业软件开发过程和提拔软件能力的一套尺度化流程管理。CMMI的全称为Capability Maturity Model Integration，即能力成熟度模型集成。这两个开发流程内容相当，认证的级别也可以相对应。
TASKING启动功能安全操持之后的全部软件（包含编译器工具集）都是基于ASPICE流程进行开发，目前公司已经通过了ASPICE 的2级认证，图 3形貌的是TASKING在ASPICE的获得2级认证的流程。对于工具置信度TCL2，可以支持到ASIL C；对于工具置信度TCL3，可以支持到ASIL B。
TASKING启动功能安全操持之后，采用ASPICE管理软件工具的开发过程。目前，已经获得了ASPICE 的CL2级评估认证。图 3展示的是TASKING获得的ASPICE CL2级评估认证的细节。对于工具置信度TCL2，可以支持到ASIL C；对于工具置信度TCL3，可以支持到ASIL B。
3.2 软件工具确认
如果采用“软件工具确认”的鉴定方法，有两种方式可以实现。
方式一：软件工具供应商进行“软件工具确认”，约请及格评估机构来对软件工具进行鉴定，并提供证实符合ASIL C 乃至ASIL D的认证证书。在这种情况下，软件工具的客户将会得到颠末认证的软件工具，另有一个安全手册，只须要应用安全手册中的指导方针，以证实他的用例与及格的用例是兼容的。
方式二：软件工具的利用方，按照“软件工具确认”的方法，自行去寻找符合的评估机构对软件工具进行鉴定，证实工具符合ASIL C或 ASIL D品级要求。工具鉴定的方法通常是颠末认证的，工具鉴定的内容可以总结为：
- 指定用例，以定义工具须要满意的需求
- 选择适当的测试来验证这些需求
- 执行测试
- 分析测试效果
- 生成安全文档
- 应用安全文档中的指导
后一种方式的缺点是存在相当多的隐性成本，例如：学习资格认证方法和相关工具，须要的测试套件许可，执行工具验证过程，与验证者交互，最后如果测试失败如那里理等。
TASKING采用第一种方式进行“软件工具确认”。TASKING VX-toolset产品在第三方机构做了专业鉴定并拿到了最高至ASIL-D品级的证书，可以提供给客户一个资格认证工具包（Qualification kit），该认证工具包中提供了所需的证据和支持文件，证实编译器在按照安全手册中的形貌利用时，适合开发达到ASIL-D的安全相关软件。工具包中提供安全手册（Safety Manual）、测试套件（Test Suite）和问题门户网站（issues portal：TASKING Issues Portal）账户。
安全手册，提供了关于如何利用工具集进行安全相关开发的指导，并且包含支持工具鉴定方法的证据。
访问TASKING Issues Portal的缺陷报告和缓解数据库的全部信息的许可，该数据库包含了有关TASKING和客户报告的全部已知工具问题的最新信息。
关于如何执行 "软件工具的验证 "鉴定方法的脚本和说明。
参考：
https://mp.weixin.qq.com/s/ZU9_J3_hYG_LoQvFJolkXQ
https://www.munik.com/newsinfo/6967514.html
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
