硬件和软件产品的开发周期

阿宝1990 2022-11-14 1356

电子说

1.3w人已加入

描述

02. V model

Hardware and Software Product Development Life-Cycle

让我们概述一下硬件和软件产品的开发周期。V模型将硬件和软件分为自己的微型V：

Summary of ISO 26262 V Model

每个V代表的总体思想保持不变；首先，您指定安全要求。然后，您将这些需求分配给系统体系结构。最后，您进行测试，集成和验证。每个V模型过程都与我们在第一课中讨论的过程相同。

但是，在硬件和软件方面还需要采取额外的措施。对于硬件，V模型包括有关硬件体系结构指标和评估随机硬件故障的部分。这是硬件V模型的更详细视图：

在软件方面，有一个体系结构设计部分以及一个单元设计部分：

在本课程中，我们将讨论随机的硬件故障以及如何制定软件安全要求。

Architectural Design vs Unit Design/结构和单元设计

软件体系结构设计是软件组件的更高层次的视图。例如，这可能是我们的车道辅助示例中的摄像机ECU。

单元是软件体系结构的一小部分。一个单元可以是一个软件驱动程序，用于从摄像机传感器读取原始数据。关于什么属于建筑设计部分而不是单元设计部分，没有硬性规定。通常，功能安全可以是一个反复的过程，在该过程中，开发V模型的新部分可能会导致前一部分的更改，反之亦然。

在下图中，您可以看到功能安全项目中涉及的内容的一般概述。您可以看到V模型的步骤已垂直延伸。通常，一个项目将具有多个系统和子系统。子系统将具有自己的软件和硬件要求。这些子系统需要集成到更大的系统中：

Functional Safety Bird's Eye View

请注意，由于需要开发定制软件和硬件，因此此处描述的“上下文”开发可能变得不切实际。为了缓解这种情况，一种常用的方法是“上下文安全元素”（SEooC），该方法考虑使用标准安全硬件和软件组件来解决功能安全实施问题。您可能会喜欢这篇有趣的论文，描述了SEooC的一种实用方法。

03. Hardware Failure Metrics

请注意，体系结构指标具有独立于实现的值，并表示为费率。硬件故障概率度量（PMHF）的绝对单位表示为每10 ^ 9小时的故障数。因此，PMHF本身不是体系结构指标，但与硬件故障指标的讨论有关。

硅的磨损是系统性故障，而不是随机的硬件故障也是有争议的，因此它可能不被视为随机硬件故障指标的一部分。

More Details about Hardware Failure Metrics

本质上，这些度量标准着眼于安全机制所涵盖的硬件故障百分比。安全机制是一些功能，可以在发生故障时保持车辆安全或检测到已发生故障。这意味着在一个安全的系统中，大多数硬件故障都会被检测到。

例子：如果RAM因紫外线辐射引起位翻转而发生故障，则安全机制将需要修复位翻转，将系统置于安全状态，和/或警告驱动程序发生故障。该标准认为硬件故障是不可避免的。但是，如果它们将要发生，那么理想情况下，它们不应导致安全问题。ASIL D的单点故障指标大于99％，而ASIL B仅大于90％。换句话说，对于ASIL D，对于特定的安全目标，应该检测到99％的单点故障或者是安全的。

要计算这些指标，您必须弄清楚哪些硬件故障会导致危险情况，哪些故障不会导致危险情况。该标准实际上将硬件故障分为六类。

Categories of Faults/故障类别

要计算硬件故障指标，您需要将故障分类为六个类别之一。我们将在此处列出它们以供参考，尽管在本课程中我们实际上不会计算硬件故障指标。

单点故障-没有安全机制来检测故障的元素中的故障。故障还会导致违反安全目标。例如，没有安全机制可纠正该错误的RAM故障将违反安全目标。

残留故障-元素具有检测某些类型故障的安全机制；但是，会出现未设计该机制进行检测的故障，并且该故障还会导致违反安全目标。例如，RAM可能具有ECC（纠错码）机制来修复位翻转；但是，由于短路而导致发生不同的故障，并且RAM没有用于短路的安全机制。

潜在的多点故障-安全机制和驾驶员无法检测到的多点故障。

感知到的多点故障-驾驶员检测到的多点故障，因为该故障导致车辆功能受限。例如，驾驶员注意到减少的刹车响应，或者在没有响应的情况下激活大灯（它们没有打开）。

检测到的多点故障-安全机制检测到的多点故障并使车辆进入安全状态

安全故障-不会导致违反安全目标的故障

多点故障的示例可能涉及RAM和ECC(纠错码error correction code) 机制。ECC纠正位翻转。如果由于位翻转而导致RAM包含故障，则ECC将纠正该翻转。如果ECC由于软件错误而失败，则RAM仍将正常工作。如果发生位翻转并且ECC失败，则将存在多点故障，因为将不纠正位翻转。RAM和ECC都将失败。

循环冗余校验（CRC）将检测到ECC机制中的故障。没有CRC，该故障将不会被发现，因此是潜在的。使用CRC，该故障将成为检测到的多点故障。如果像警告灯一样告知驾驶员有关故障，则这是可感知的多点故障。

Measuring Faults/测量故障

您将如何实际测量故障和失效率？您可以：

进行现场测试以测量给定时间内的故障数量
使用来自等效或类似系统的现有数据
供应商也应提供用于计算这些指标的数据。

请注意，ISO 26262未指定随机硬件故障的目标。有一个针对硬件故障的概率度量（PMHF），它着眼于每个安全目标的危险，未检测到的硬件故障。ISO 26262建议仅在没有数据支持目标的情况下使用PMHF值。这是一篇有关PMHF和随机硬件故障的有趣论文。

故障的来源和类型

电阻器并不是唯一会发生故障的硬件组件。还需要考虑整个处理单元。

硬件寄存器，内部RAM，控制器逻辑以及其他组件可能会发生故障。所有这些故障都需要满足安全要求，然后分配给体系结构并记录在安全概念中。安全概念将讨论如何检测或避免这些故障。

04. Programming Languages

Notes about Programming Languages

任何编程语言都会有长处和短处。C ++的一个优势是能够编写具有许多输入输出操作的高速软件的能力。另一方面，C ++允许您将浮点数存储在布尔变量中。而且C ++在运行时错误检查方面没有提供太多帮助。

MISRA C ++标准讨论了适用于安全关键型应用程序的C ++子集。该标准包含一组有关如何在汽车应用中使用C ++语言的规则。

Software Tools & Software Tool Confidence Level

汽车软件工程师使用各种工具来帮助开发软件。

编译器是软件工具的一个示例。其他示例包括版本控制软件，测试工具，自动生成代码的图形建模工具以及有助于确保MISRA遵从性的工具。

功能安全标准要求您对软件工具进行资格验证，以确保它们适合于安全关键型应用程序；使用自动化代码生成和代码测试的软件工具变得越来越普遍。例如，如果测试工具有问题，则可能无法检测到代码错误。

ISO 26262描述了一种度量标准，用于衡量您对工具的信心。该度量标准称为工具置信度或TCL。

评估置信度需要考虑以下两点：

工具影响（TI）-工具本身是否可能发生故障并违反安全目标
工具错误检测能力（TD）-如果工具发生故障，是检测到还是停止了故障

然后，您可以使用TI和TD度量标准来计算工具的置信度级别.ASIL较高的软件块需要TCL1，这是最高置信度。TCL3是最低的置信度等级。

具有TCL2和3等级的低置信度工具需要进行鉴定。合格包括通过严格的测试来运行该工具，以证明它不会引起任何错误。软件工具供应商提供了鉴定工具包，可帮助您在自己的环境中测试他们的工具。

05. MISRA C++ Lab

MISRA Lab

MISRA C ++标准
MISRA C ++标准定义的C的子集++拨出对安全关键AUTOMATIVE应用程序。该标准包括数百条有关在开发汽车软件时如何使用C ++语言的规则。
通常，软件工程师会使用代码合规性检查包来确保其代码符合标准。在本实验中，您将收到有效的C ++ Kalman过滤器代码，其中包含许多MISRA违规行为。您的工作将是修复错误，并使代码尽可能接近合规性。
MathWorks 为您提供了MISRA合规性检查软件的试用版，该软件称为 Polyspace 。Polyspace是业界用于编写与MISRA兼容的C ++代码的最常用软件程序之一。该程序是称为MATLAB的较大的数学和工程工具套件的一部分。
这是有关MATLAB及其在工程和科学中的用法的视频。

Polyspace Use Case

另外，在您开始实验之前，请查看此用例，以了解一家汽车公司如何使用Polyspace改善其代码质量：链接至用例。

安装MATLAB Polyspace

由于的支持 MathWorks ，MATLAB和Polyspace的免费下载许可证是
在课程期间可用。

如果您还没有MathWorks帐户，请创建一个新帐户。
在此处访问MATLAB的免费许可证：下载链接。
如果您在安装MATLAB时遇到问题，请在“知识”或“功能安全性”项目通道的“学生中心”中搜索或发布您的问题。请提供您的操作系统以及错误之前采取的步骤的列表。错误的屏幕截图通常也很有帮助。
您可以在上找到MATLAB的系统要求 MathWorks网站。

设置实验室

安装MATLAB Polyspace之后，就可以开始实验了。在此页面的底部，您将看到一个链接，上面显示“支持材料：适用于Udacity的Psprj”。下载并解压缩该文件夹。
在文本编辑器中，打开fileroot / Polyspace / kalmanFilterProject_original.psprj。您将在第13-18行，第34-39行和第45行看到包含路径。应将它们替换为本地文件夹的相应路径。保存并退出文本编辑器。
例如，
在Mac上：

在Windows计算机上：

启动Polyspace

使用快捷方式启动Polyspace
matlabroot/polyspace/bin/polyspace.exe
其中matlabroot是MATLAB安装目录（通常称为MATLAB / r2017a）
在Mac上，您还可以通过以下方式启动该程序：

转到应用程序文件夹
右键单击“ MATLAB_R2017a”，然后选择“显示包装内容”
单击polyspace文件夹，然后单击bin文件夹（polyspace-> bin）
右键单击“多边形”，然后选择“打开”

打开项目文件并运行错误查找器

打开项目文件 fileroot/Polyspace/kalmanFilterProject_original.psprj在“多边形”窗口中。
单击“运行错误查找器”。MISRA C ++结果应该自动出现。
在分析过程中，您可能会看到一个良性弹出错误。您可以单击以结束错误的后台处理，分析将正常完成。此错误不会影响MISRA分析。此错误通常不会在Mac上出现，但可能会在Linux和Windows系统上出现。

完成实验

软件概述

首次打开多边形时，该程序将概述软件的工作方式。以下是需要注意的主要事项：

“项目浏览器”选项卡：显示Polyspace项目的结构
结果列表选项卡：MISRA违规列表
运行错误查找器按钮：检查代码是否符合MISRA
配置窗口：无需在此处进行任何更改
仪表板：显示错误分析的进度
输出摘要：分析的摘要结果

要进行实验：

该实验室的代码应该看起来有些熟悉。它是扩展的卡尔曼滤波器。
打开.psprj文件后，单击窗口顶部的“运行错误查找器”。
分析将运行，您可以在“输出摘要”选项卡中观察进度。分析时间相对较短（似乎需要3-4分钟才能得出平均值）
“结果列表”选项卡将显示所有违反MISRA的行为
您可以单击不同的违例，这将在“源”选项卡中打开代码。
如果右键单击违规，则可以选择在编辑器中打开代码：“打开编辑器”。然后，您可以编辑并保存代码以解决违规问题。
在“源”选项卡中，您也可以滚动查看代码以查看有违规的地方。违规行为用紫色三角形标记，单击三角形将突出显示违规行为。
在“结果详细信息”窗口中，如果单击问号，则会打开“上下文帮助”窗口。上下文帮助列出了所有MISRA C ++规则。通读规则有助于理解代码的问题。

每次您想查看代码是否固定时，都需要再次单击“运行错误查找器”。如果您想一次仅对一个文件运行分析，请转到：
“项目浏览器”选项卡->项目源文件-> src原始

然后右键单击要从分析中排除的文件，然后选择“排除文件”。您会注意到，“ main.cpp”已从分析中排除，因此您只需关注卡尔曼过滤器代码即可。

06. Software Safety Life-cycle/

Software Safety Requirements, Architecture, Testing and Integration

软件V图

在视频中，我们简化了软件安全性V模型，以显示软件安全性生命周期涉及与功能安全性分析其他级别相同的四个步骤：

规定安全要求
设计架构并将需求分配给架构
软件测试
软件整合

这是软件安全生命周期的稍微详细的版本：

ISO 26262软件V模型

开发软件体系结构应同时考虑安全性和非安全性要求。软件安全要求和软件产品要求不能分为两种不同的体系结构；软件体系结构将产品要求和安全要求混合在一起。
架构设计可能涉及多个微控制器或ECU。因此，需要指定软件接口，数据路径，过程序列和定时行为。

软件单元

通常将软件体系结构进一步细化为称为单元的较小部分。因此，技术安全要求导致了软件安全要求，这些要求被进一步细化为软件安全单元要求。然后，单元需求将导致体系结构的进一步完善。

测试规格

在V模型的右侧，从安全要求中得出测试规格和测试用例。请记住，V模型具有层次结构级别。当您升级具有更高系统级别的V模型集成软件时，每个阶段都需要进行自己的测试。

07. Software Safety Requirements Lane Departure Warning

Software Safety Requirements - Lane Departure Warning Amplitude Malfunction

就本模块而言，我们不希望您得出软件安全要求。但是下面的示例应该使您了解如何从技术安全要求中得出软件安全要求。这些示例还显示了技术要求和软件要求之间的主要区别；软件要求比技术要求更为具体。软件要求指定了变量名称，信号路径以及软件协议和机制。软件工程师应该能够根据软件需求和软件体系结构编写程序。

我们将向您展示从技术安全要求中衍生出来的软件安全要求的示例。首先，我们将向您展示精致的体系结构，然后解释我们添加的所有新元素：

Software Architecture Diagram

Software Safety Requirements Derived from Technical Safety Requirement 01

让我们一次查看一下我们的技术安全要求，并得出软件安全要求。当我们解释新功能时，您可能需要参考此图。

这是我们的第一个技术安全要求：

ID	Technical Safety Requirement	ASIL	Fault Tolerant Time Interval	Allocation to Architecture	Safe State
TechnicalSafetyRequirement_01	The LDW safety component shall ensure that the amplitude of the LDW_Torque_Request sent to the Final Electronic Power Steering Torque component is below Max_Torque_Amplitude	C	50ms	LDW Safety	LDW torque output is set to zero

我们将把LDW安全组件分为三个部分。

第一个块将从基本/主车道辅助功能组件获得扭矩请求。该第一块将进行所需的任何预处理。然后，该块将结果发送到扭矩限制器块，该块将检查扭矩是否超出允许的最大幅度。如果达到极限，扭矩请求将设置为零。最后，我们将添加第三个块，该块准备好将信号传输到最终扭矩生成器。

这是新的软件安全要求：

将这些新软件安全要求与新系统架构图进行比较。

让我们看一下第二项技术安全要求。

可以使用称为End2End（E2E）协议的协议来解决此要求。在本课结束时，我们将在标有“免受干扰的自由-通信”的部分中讨论该协议。

以下是从技术安全要求02衍生的软件安全要求：

Software Safety Requirements Derived from Technical Safety Requirement 03

为了解决停用要求，我们将添加一个错误检测块，作为对关闭车道保持系统的额外检查。每个软件模块将输出有关是否发生错误的信号。该信号将与实际扭矩请求一起发送到“ Final EPS Torque Generator”块。

这是新的软件安全要求：

Software Safety Requirements Derived from Technical Safety Requirement 04

Our fourth technical safety requirement discusses sending an error signal to the car display ECU:

这是技术安全要求编号04的软件安全要求：

Software Safety Requirements Derived from Technical Safety Requirement 05

以下是内存测试的典型软件安全要求：

Final Project

在最终项目中，您将需要记录此页面上显示的信息。该信息将包含在“软件安全要求和体系结构帮助”文档中。

08. Other Sources of Software Safety Requirements

至此，您已经拥有完成最终项目所需的所有信息。本课程的其余部分重点介绍软件安全要求的一些最重要来源。
许多软件安全要求直接来自于技术安全要求。但是，除了技术安全要求之外，还有其他软件安全要求的来源：

确保软件健壮性和质量的要求
确保不受干扰的要求

下图显示了软件安全要求的三个来源：

如果不是汽车功能安全方面的头号错误源，那么软件错误是一个非常重要的错误源。您对安全性至关重要的软件了解得越多，您的软件安全性要求就会越好。

软件鲁棒性和质量

09. Freedom from Interference - Spatial

Mechanisms for Ensuring Freedom From Spatial Interference/空间

有一些通用的机制可确保不受空间干扰，例如内存保护单元和相关数据的双重存储。

MPU是一种预防方法，因为它可以阻止元素访问不应访问的内存。可以对MPU进行编程，以设置软件元素之间的正确读取，写入和执行权限。

相关数据的双重存储（例如带2的补码）是一种检测方法。使用2的补码，您可以检测到数据已更改并且不再有效。但是您将无法再使用数据。

其他防止内存干扰的机制包括：

诸如CRC之类的冗余检查，以确保数据不会意外更改。
具有存储器错误检测和纠正功能的微控制器
允许软件单元拥有自己的虚拟内存空间的操作系统

提到的一种机制是存储的 2补码安全相关数据。2的补码是表示二进制整数中的负整数的一种方式。

CRC （循环冗余校验）是，以检查是否在数据传输期间已经改变的一种方式。它们的工作方式是在数据上添加一个值，然后确保该值在传输过程中没有改变。

请注意，要解决死锁，禁用将阻止进程抢占的OS中断效率低下，并且可能会损害总体响应时间和系统延迟。替代方案是由实时操作系统（RTOS）提供的功能，它是优先级上限。

10. Freedom from Interference - Temporal/时间干扰

解决死锁

有多种避免死锁的算法，包括称为禁用中断的措施。启用中断后，一个进程可以中断另一进程。因此，在我们的示例中，线程1需要资源B并试图获取A。但是线程2继续中断线程1来获取A。禁用中断将允许线程一获取A。

免于时间干扰的机制

避免时间干扰的机制包括循环执行调度，基于固定优先级的调度，时间触发的调度，处理器执行时间的监视，程序序列监视和到达速率监视。

11. Freedom from Interference - Temporal Part 2

13. Freedom from Interference - Communication/通信干扰

通信干扰的常见原因

导致通信故障的原因很多。这些原因将在软件安全分析中或有时在技术安全分析中进行分析：

信息重复
信息丢失
信息延迟
信息插入
伪装或不正确的信息寻址
信息顺序错误
信息腐败

确保不受通讯干扰的其他机制

有一些避免通信干扰的措施。这些机制可用于定义有助于避免通信故障的软件安全要求。确保不受干扰的机制包括：

信息回送
信息确认
I / O引脚的适当配置
优先公交仲裁
端到端协议

例如，一项技术安全要求是“应确保“ LDW_Torque_Request”信号的数据传输的有效性和完整性”。该技术安全要求可以细化为软件安全要求，即数据应由End2End机制保护。

端到端保护协议的示例规范

端到端协议示例

该机制涉及在传输数据时添加两个额外的数据字节，称为CRC（循环冗余校验）和SQC（序列计数器）。要计算CRC，您可以对要传输的数据运行数学公式。然后，您可以在传输之前将CRC结果附加到数据上。接收到数据后，将再次对数据集运行数学公式。数据附带的CRC和接收端计算出的CRC应该相同；否则，数据数据可能已在传输中损坏。
SQC只是一个与数据一起发送的计数器。这样，接收者可以确保消息没有丢失。

车道偏离警告（LDW）的E2E软件安全要求

在“软件安全要求车道偏离警告”的概念中，我们已经讨论过可以通过E2E协议处理技术安全要求02。让我们更深入地了解此技术要求和相关的软件安全要求。这是技术安全要求：

这也是软件安全体系结构

System Software Architecture

可以看到我们为 LDW Safety 组件的两个信号增加了E2E Calculation. 我们需要确保当’Processed_LDW_Torque_Request’信号传送到“ Final EPS Torque Generator”时没有损坏。E2E Calculation组件将对要传输的信号进行计算，并将计算结果附加到信号上。

然后， "Final EPS Torque Generator"组件将运行相同的计算，并比较传输前后的结果。如果结果相同，则可以假定数据保持不变。

当“ LDW_Safety_Activation”组件将其信号发送到“ Final EPS Torque Generator”时，我们将使用相同的机制。

因此，这里再次是软件安全要求：