项目定义，也就是对要进行研发的产品进行一个定义，进行一个描述。主要有两个目的：一个是
风险的分类主要是通过3 个指标来考量，即：危险发生时导致的伤害的严重性、在操作
首先，来看伤害的严重性。这里的伤害是指危险事件发生时，对所有被卷入事件中的人的伤害，包括车上的司机和乘客，骑自行车的人，行人，其他车辆上的人员。伤害的严重性可以分为 4 个等级，即：S0，S1，S2，S3（对于伤害严重性的详细描述可以参考 ISO26262-3中附录 B 的内容，这里只做分级说明）。如下表：
其次，来看在操作条件下暴露于危险中的可能性。可能性被分为 5 个等级，即：E0，E1，E2，E3，E4，具体分级见下表。至于暴露值是选 E1 还是选 E2，主要看车辆在目标市场正常、合理的使用情况。这里要注意的是，评估暴露于危险中的可能性并不考虑在车上安装了多少个要评估的产品，且假设了所有的车上都安装了这个产品。对于那种认为不是每辆车都安装的产品，其相应的暴露在危险中的可能性会减小的说法也是错误的。
这里，E0 只用于在风险分析中一些建议性的情况，通常如果一个危险，人员暴露其中的可能性是 E0 级，则无需考虑 ASIL 等级。再次，来看可控性。即危险事件能被司机或者其他交通参与人员进行控制并减小或者避免伤害的可能性。在 ISO26262 中，可控性被分为 4 个等级，即：C0，C1，C2，C3。但要注意，使用这个分级的条件是司机处于正常状态，即：不疲劳，有驾照，按照交通规则行驶，当然，其中要考虑可预见的误操作和误使用。四个级别为：
其中，C0 通常用于不影响车辆安全操作的情况。如果一个危险的可控性被评为 C0，则对其没有 ASIL 要求。由此，根据以上的三个参数，即可确定风险分析中每个风险相应的 ASIL 等级（汽车安全完整性等级），具体确定方法如下表：
ASIL 等级分为 A、B、C、D 四个等级，ASIL A 是最低的安全等级，ASIL D 是最高的安全等级。除了这四个等级 QM 表示与安全无关。在风险分析过程中，要确保对每个危险事件，根据 S、E、C 和具体的操作条件和模式确定的 ASIL 等级不低于其安全目标的要求。同时，相似的安全目标也可以合并为一个安全目标，但要达到的 ASIL 等级应该是合并项目中最高的。如果安全目标可以被分解到具体的状态中，那么每个安全目标也要转换成达到安全目标的具体安全状态下的具体要求。
安全目标及其属性（ASIL）应按照 ISO26262-8:2011，第 6 条款规定。要注意的是，危险分析、风险评估和安全目标都要进行审核，以保证对条件和危险分析完整，符合项目定义，并与相关的危险分析和风险评估一致。由此，完成概念阶段的危险分析和风险评估，形成减少和防止危险发生的安全目标，并通过验证审核。
做完危险分析和风险评估之后，在概念阶段，ISO26262-3 还给出了功能安全概念这个阶段。其主要目的是通过前面的危险分析和风险评估之后得出的安全目标来确定具体的功能安全要求，并将它们分配到初步的设计架构，或者外部减少危险的措施当中去，以确保满足相关的功能安全要求。
对于这种分析方法，风险（R）可在危险事件被描述为一个函数（F），与危险事件的发生频率（f），即通过的人的及时反应避免特定的伤害或损害能力，损害或损伤的可控性（C），以及潜在的严重程度（S）有关。
发生的频率 f 有以下几个因素确定，一个需要考虑的因素是危险事件的频繁度和在危险事件涉及的人数。在 ISO26262 中，这个的度量是简化成暴露于危险中的可能性（E）。另一个因素是，有可能导致危险事件（故障率，λ）的产品故障率，故障率的特点是硬件随机故障和系统性故障：
危险分析和风险评估用来设置功能安全要求，这样项目风险是可以避免的。ASILs 等级导出的危害分析和风险评估确定出项目的功能安全要求最小集合。
系统级产品开发启动的目标是确定和规划在系统开发各个子阶段的功能安全活动。这部分内容在 ISO26262-8 中也有描述。系统级安全活动包含在安全计划中。系统开发的必要活动如下图所示，产品开发启动和技术安全需求说明之后是系统设计。在系统设计过程中，系统体系结构建立以后，技术安全要求被分配到的硬件和软件部分，如果合适的话，分配到其它技术。从系统架构所增加产生的需求，包括硬件，软件接口（HSI），对技术安全要求进行细化，依据体系结构的复杂性，对子系统的需求依次地导出。之后，硬件和软件部分进行集成和测试，然后进行装车测试。一旦到装车测试的水平，执行安全确认，以提供达到安全目标的功能安全证据。系统级产品开发启动的安全活动是计划设计和集成过程中适当的方法和措施。
这个阶段的第一个目标是规范技术安全需求。该技术安全需求说明细化了功能安全的概念，同时考虑功能性的概念和初步的体系架构。第二个目标是通过分析技术安全需要来验证符合功能安全需求。
在整个开发生命周期，技术安全需求是要落实功能安全概念的技术要求，其用意是从细节的单级功能安全要求到系统级的安全技术要求。
技术安全需求规范；安全机制；ASIL分解；潜在故障的避免；产品、运行、维护和结束；检验和确认。
这个阶段的第一个目标是进行系统设计、开发符合项目技术安全需求规范的功能要求。第二个目标是校验系统设计和功能要求。
系统设计和基于项目技术安全需求规范的技术安全概念来源于功能安全概念。为了开发一个系统架构设计，功能性安全要求，技术安全要求和非安全相关的要求被完成。因此，在这个阶段安全和非安全相关的要求都在这个过程中处理。
集成和测试阶段包括三个阶段和两个主要目标如下所述：第一阶段为每个项目包含的元件的硬件和软件的集成。第二阶段是一个项目的元件的集成以形成一个完整的系统。第三阶段是项目与车辆的周围系统的集成。
集成过程的第一个目标是根据 ASIL 等级和安全需求规范测试符合各项安全要求。第二个目的是验证“系统设计”覆盖的安全要求正确地由整个项实施。项目元件的集成是在从软件硬件集成，系统集成到整车集成系统。 集成测试会在每个阶段的执行来证明系统元件正确交互。根据 ISO26262-5 和 ISO26262-6 完成硬件和软件的开发，然后按照第 8 条款（项目集成和测试）开始进行系统集成。
第一个目标是提供符合安全目标和适用于该项目的功能安全概念的功能安全性证据。第二个目标是提供证据证明的安全目标是正确的，完整的，在车辆级别可以实现的。之前的验证活动（如设计验证，安全分析，硬件，软件和项目集成和测试）的目的是为了提供证据，证明每个特定活动的结果符合规定要求。在代表性的汽车集成项目的验证的目的是对预期用途提供恰当的证据和确认安全措施的充足性。
该条款的第一个目标是规定硬件安全需求，参考技术安全概念和系统安全规范。第二个目标是验证硬件安全需求与技术安全概念和系统安全规范一致。更进一步的目标是详细描述软硬件接口规范 HSI。技术安全需求分配到软件和硬件，硬件安全需求进一步详细,考虑设计约束,这些设计约束在硬件上的影响。硬件安全需求规范应该是硬件上的技术安全要求，应该包含如下内容：
1） 硬件安全需求和相关安全机制的属性来控制硬件单元的内部失效,这包括内部安全机制覆盖瞬态故障,例如,使用的技术。相关属性可以包括定时器和看门狗检测
2） 硬件安全需求和相关安全机制的属性能够承受外部单元的失效。例如在 ECU 外部 失效时，对 ECU 输入开路
5） 硬件安全需求不指定安全机制 产品硬件的设计验证标准，包括环境条件（温度，振动，电磁干扰，等），具体的操作环境（电源电压，任务历程等）和特定组件的要求。硬件安全要求应按照 ISO 26262-8:2011 条款 6 和 9 验证，具有以下属性：
硬件架构设计；硬件详细设计；安全分析；硬件设计验证；生产 、 运行 、 服务和关闭；
这个子阶段的目标是计划和启动软件开发的功能安全活动。软件开发的启动是计划活动，其中软件开发子阶段及其支持过程（见 ISO26262-8 和 ISO26262-9）是根据项目发展的程度和复杂性决定和计划。软件开发子阶段和支持流程是通过确定适当的方法启动，以符合有关规定和各自的 ASIL。方法是指通过指南和工具， 对于每个子阶段支持。
这个子阶段的第一个目标是拟定软件安全需求，他们是来自技术安全概念和系统设计规范。第二个目标是细化软硬件接口要求，依据 ISO26262-4:2011，第 7 条。第三个目的是验证该软件的安全要求和硬件的软件接口要求与技术安全概念和系统设计规范一致。
NOTE1 ASIL 分解是一种 ASIL 裁剪方法，这种方法可以应用在一个条款或要素的功能、技术、硬件、软件安全要求。
NOTE2 作为一个基本规则，ASIL 分解需要分配给充分独立的架构模块的安全要求是冗余的。
NOTE3 在一致性冗余的应用中（比如：备份设备和软件）和考虑到软硬件的系统性失效，ASIL 不能降低除非失效分析充分表明足够的独立性存在或者潜在的一般原因不会导致危险。因此，一致性冗余一般来书不是充分条件对于降低 ASIL 等级，这是由于在组件之间缺少足够的独立性。
NOTE4 一般情况下，ASIL 分解不适用于那些在多通道架构设计中的通道选择和开关。 一般情况下，ASIL 分解允许在多个组件中以一个安全要求为目标的 ASIL 分摊 以确保相同安全要求的兼容。在一个预期功能和他对应的安全机制之间的 ASIL 分解在特定条件下是允许的（见 5.4.7）。对于由于随机硬件失效造成的包括硬件架构矩阵评估和违反安全目标评估（见ISO26262-5）保持不变。
