1
¿Qué es la seguridad funcional?
1
Fondo
Debido a la complejidad de los automóviles, la industria está trabajando para proporcionar sistemas de componentes que cumplan con los requisitos de seguridad. Por ejemplo, en el sistema de acelerador por cable, cuando el conductor pisa el pedal del acelerador y el sensor del pedal envía una señal al controlador, el controlador analizará exhaustivamente las señales, como la velocidad del motor, la velocidad del vehículo, la posición del pedal , etc., y luego envíe el comando de control a la ontología del acelerador. Probar y validar sistemas como los sistemas de aceleración por cable es un desafío para la industria automotriz. El objetivo de ISO 26262 es proporcionar un estándar de seguridad unificado para todos los sistemas E/E automotrices.
El borrador del estándar internacional de seguridad funcional ISO-26262, nacido de IEC-61508, se publicó en junio de 2009. Desde la publicación del borrador, ISO-26262 ha ganado una amplia atención en la industria automotriz. Los ingenieros consideran que ISO-26262 es lo último en tecnología. El estado del arte de la tecnología es el más alto estado del arte en el que se ha desarrollado un dispositivo o proceso en un momento dado. Los fabricantes de automóviles generalmente son responsables de los daños causados por fallas en los productos. ISO-26262 es un estándar común en la industria automotriz que proporciona una forma de medir la seguridad del sistema.
Figura 1: Sistemas relacionados con la seguridad
ISO-26262 utiliza el modelo V para gestionar la seguridad funcional y regular el desarrollo de productos a nivel de sistema, software y hardware. El estándar ISO-26262 proporciona regulaciones y recomendaciones a lo largo del proceso de desarrollo del producto, desde la etapa de concepto hasta el final de la vida útil del producto. Detalla cómo asignar un nivel de riesgo aceptable a los sistemas y componentes y documenta todo el proceso de prueba. En general, ISO 26262:
Proporciona todo el ciclo de vida de seguridad del vehículo (gestión, desarrollo, producción, operación, servicio, desmantelamiento) y apoya la personalización de las actividades necesarias durante estas fases del ciclo de vida;
Proporciona un enfoque basado en el riesgo específico del automóvil para determinar la clase de riesgo (ASIL);
Utilice ASIL para especificar los requisitos de seguridad necesarios para que un proyecto logre un riesgo residual aceptable;
Proporciona requisitos para las medidas de verificación y validación para garantizar un nivel de seguridad adecuado y aceptable;
2
Evaluación de riesgos: análisis de peligros y evaluación de riesgos (HARA)
Cuando tenemos una definición clara de los modelos desarrollados recientemente, también disparamos el primer tiro de seguridad funcional automotriz. Necesitamos HARA para identificar y evaluar los peligros potenciales. Por lo general, el ingeniero de seguridad funcional de un OEM realiza un análisis HARA en las funciones a nivel del vehículo para identificar escenarios de peligro potencial y determinar el nivel de reducción de riesgo requerido para cada peligro potencial. HARA tiene en cuenta la frecuencia y la duración de la exposición a situaciones potencialmente peligrosas en un escenario de conducción específico (Exposición), la cantidad de control requerida para corregir el mal comportamiento para mitigar el peligro potencial (Controlabilidad) y la gravedad de las posibles consecuencias cuando se produce el comportamiento de mal funcionamiento (Gravedad).
HARA se realiza en características a nivel de vehículo, no a nivel de componente o elemento. Para cada peligro potencial, se consideran una serie de posibles escenarios de conducción. Por ejemplo: en un sistema de mitigación de colisión frontal, el peligro potencial de un frenado involuntario se evalúa de acuerdo con diferentes escenarios de conducción, como la velocidad de funcionamiento y las condiciones de conducción.
3
Asignación de niveles de seguridad: niveles de integridad de seguridad funcional (ASIL)
Durante el proceso HARA, los OEM asignan una calificación ASIL (Nivel de integridad de seguridad automotriz) a cada riesgo potencial identificado. ASIL se determina durante el proceso de desarrollo. Según los posibles riesgos.
Figura 2: Evaluación del nivel de seguridad funcional
Por ejemplo, si falla el velocímetro de cierto automóvil, no se mostrará ninguna información desde el inicio del automóvil.La escena se puede clasificar como QM, porque el conductor puede percibir fácilmente la falla y optar por no conducir o conducir con mucha precaución. En otras palabras, la controlabilidad del escenario es muy alta y la severidad es muy baja. Por el contrario, una situación en la que un conductor no frena a altas velocidades puede clasificarse como ASIL-D si el vehículo no puede controlar el vehículo debido a la alta probabilidad de lesiones graves.
Para abordar adecuadamente estas situaciones, ISO 26262 utiliza clasificaciones ASIL para determinar el rigor de los pasos de desarrollo que deben tomar los proveedores y define los requisitos para los objetivos de seguridad:
1. Tasa FIT (Falla en el tiempo): La tasa FIT es la tasa de falla aceptable de un vehículo dentro de un período de tiempo determinado. Los vehículos deben cumplir con las tarifas FIT especificadas por la calificación ASIL, pero los OEM también tienen la flexibilidad de elegir tarifas FIT para los componentes subyacentes dentro del sistema.
2. 安全概念（Safety Concept）：安全概念决定如何检测顾故障及如何控制故障，具有更高ASIL评级的系统需要更严格的故障检测和响应能力。
3. 安全要求（Safety Requirements）：安全要求规定了对任何给定故障的适当响应。比如，传感器检测到与内部安全相关的问题，如内存损坏，故障响应系统可能会在规定的时间内终止通过控制器的通信，以便向其他系统指示其故障状态。这是安全要求所描述的典型的安全机制——但故障响应系统并不总是恰当合适的。如：对于智驾功能，车辆可能采用故障操作系统，这要求冗余系统接管必要的时间，以使车辆处于最小的风险状态（比如，安全停车在路边）。对于系统故障，遵循严格的开发过程有助于增加该功能将以一种安全的方式运行的信心。
4
持续的测试和集成
汽车功能安全在整个开发过程中都采用了V模型。V模型要求，对于开发的每一步骤，在测试中都必须对应有一个相应的步骤。供应商定期评估其开发过程，以确保硬件和软件开发都遵循了所需要的步骤。
图3：V字开发模型
OEM，供应商或者独立的第三方公司对所有相关的工作产出物进行功能安全审核和评估，以确保功能安全的实现。功能安全需求一个全面的管理过程，以确保适当的监督和完整的系统集成。
2
什么是功能安全工程师，
功能安全工程师做什么？
关于什么是功能安全工程师？这个问题乍一看很好回答，但如果仔细思考下就会发现，想找到真实统一的答案却并不容易。比如拥有完善开发体系流程的大公司和初创的小公司，他们对功能安全工程师的定义大概率是不同的。思来想去，还是决定以一个新项目为例，来说明下什么是功能安全工程师以及在产品开发过程中功能安全工程师做什么。
1
报价阶段
1. 安全要求的分析与澄清：
功能安全工程师要对客户的安全输入进行分析，以确认公司内部产品的安全要求是否与客户匹配。通常会以会议的形式跟客户讨论和澄清相关安全要求。
2. 执行影响分析：
分析完客户的安全要求之后，一般功能安全工程师还会做影响分析，以确定公司内部的平台项目或者已经量产的其他客户项目是否有可以直接复用的功能，或者修改之后可以复用的功能。如果是全新的产品开发，则客户忽略影响分析。
3. 开发接口协议（DIA）责任划分：
弄清楚产品的开发边界之后，功能安全工程师要跟客户去确定每一方的开发责任范围，并明确开发过程中的产出物的责任方以及双方如何进行产出物的交互，双方对以上内容都打成一致后，DIA也就完成了。最后别忘了双方都需要在DIA上签字。
4. 准备项目功能安全计划和安全档案：
在报价阶段，功能安全工程师要根据项目的时间计划以及客户的安全输入来准备初版的项目功能安全计划（主要内容是计划管理和指导整个项目开发过程中的安全活动的执行，包含日期、关键节点、任务、可交付的成果、职责和资源等）以及安全档案（主要内容是与客户阐明所开发的产品已经按照ISO 26262的要求进行开发并实现了功能安全所准备的证据，包含产品开发各个阶段的关键产出物的记录，产出物的评审记录等）。
5. 准备评审会议：
以上内容都完成之后，功能安全工程师就可以跟审核员（Assessor）约评审会议了。在会上，审核员会根据功能安全工程师准备的证据对该项目的产品开发成熟度进行评估以确认是否满足当前的开发需要，以及是否有安全相关的风险，并输出当前阶段的评估报告。【注】：由于每家公司的开发流程不同，所以对功能安全评估次数要求也不同，但基本都会在项目的关键节点进行功能安全评估。
6. 相关项定义以及危害分析：
如果站在主机厂角度，功能安全工程师要完成所开发产品的相关顶定义（主要内容是在整车层面对相关项进行定义和描述，包括功能，及其与驾驶员、环境和其他相关项之间的依赖性和相互之间的影响），并对其进行危害分析和风险评估（主要是识别并分类由相关项中的功能异常表现引起的危害事件，以及定制防止危害事件发声或者减轻危害程度的安全目标及其安全等级，来避免不合理的风险），以便得出产品的顶层功能安全目标，以及功能安全概念，并打包发给供应商。
2
概念设计阶段
功能安全概念/要求开发：功能安全工程师要完成功能安全概念/要求（FSC/FSRs）的开发。功能安全概念的主要目的如下：
1) 要根据功能安全目标定义产品的功能性或者降级的功能性行为；
2) 要根据功能安全目标定义关于合理地、及时地检测和控制相关故障的约束条件；
3) 要定义产品层面的策略或者是措施，以通过产品本身、司机或者外部的措施来实现故障容错或者减小对相关故障的影响；
4) 把功能安全要求分配给系统架构设计；
5) 确认功能安全概念并且定义号安全确认的准则；
图4：功能安全目标和安全要求层级
3
开发设计阶段
系统开发设计
1. 技术安全概念/要求开发：
功能安全工程师要完成（或者协助系统需求工程师完成）TSC/TSRs的开发。技术安全概念的主要目的如下：
a. 制定系统要素和接口关于功能、相关性、约束和属性方面实施中所需的技术安全要求；
b. 制定系统要素和接口实施安全机制的技术安全要求；
c. 制定在生产、运行、服务和报废中系统及其要素功能安全的相关要求；
d. 验证技术安全要求在系统层级是否符合功能安全要求并与功能安全要求一致；
e. 制定满足安全要求且不与非安全相关要求冲突的系统架构设计和技术安全概念；
f. 分析系统架构设计，防止故障并为生产和服务得出必要的安全相关特殊特性；
g. 按照各自的ASIL等级，验证系统架构设计和技术安全概念是否适用于满足安全要求；
图5：系统层面的产品开发
2. 安全机制的裁剪：
一般在产品设计初期，开发人员已经完成了关键芯片（比如：Micro-controller, SBC, ASIC, Driver ICs, Intelligence Sensor等）的选型。功能安全工程师在此阶段还要主导完成对芯片手册安全机制的裁剪活动，哪些是产品所必须用到的，哪些是可以裁剪的，并给出充分的理由。
3. 系统安全架构开发：
有了系统需求，系统架构，功能安全要求和技术安全要求后，功能安全工程师就可以开始设计（或者协助系统架构工程师设计）系统安全架构了。设计系统安全架构要注意以下几点：
a. 确保系统安全架构和前面阶段的系统架构设计的一致性；
b. 系统安全架构要能实现技术安全要求；（相应的安全要求和安全机制最好能体现在系统安全架构中）
c. 设计的系统安全架构能否被充分验证，预期的软硬件设计是否能满足此系统安全架构，是否方便于系统集成时测试的执行；
d. 设计时要充分考虑安全相关的内部和外部接口；
e. 如果此阶段需要进行ASIL等级的降级分解，要按照ASIL的要求进行分解；
4. 启动系统层面的安全分析：
有了完整的安全要求和系统安全架构之后，功能安全工程师就可以启动系统层面的安全分析（FMEA分析，FTA分析，DFA分析）了。执行安全分析的主要目的在于：提供证据证明系统设计实现了相应ASIL等级的功能安全要求、识别失效原因和故障影响、识别或者确认安全相关系统组件和接口。
a. FMEA分析：FMEA是一种定性的、归纳式的单点故障分析方法，主要是在早期检测和消除产品设计和制造过程中的薄弱点。
b. FTA分析：FTA是一种演绎式故障分析，它使用布尔逻辑来分析系统不期望的状态，以结合一系列较低级的事件。FTA的目标是分析在系统中发生的实际故障的路径，以定位系统故障的原因。
c. DFA分析：DFA的主要目的是通过分析潜在原因或者诱发因素，来确认设计中已经充分实现了要求的独立性（Independence独立性是指在两个或者多个元素之间没有级联故障和共因故障，从而可能导致违背安全目标），或相互之间免于干扰（FFI免于干扰是指在两个或者多个元素之间没有可能导致违反安全要求的级联故障）。如果有必要的话，也可以制定相应安全措施，来减轻可能的相关失效。
图６：不同类型的相关性失效之间的关系
硬件开发设计
1. 硬件安全要求开发：
有了系统层面的安全要求、安全架构和安全分析的输入后，功能安全工程师就可以开始开发（或者协助硬件工程师开发）硬件安全要求了。硬件安全要求主要从分配给硬件的技术安全要求和系统架构设计中导出。
图７：硬件层面的产品开发
2. 硬件安全架构设计：
硬件安全架构设计主要是硬件架构师来负责，功能安全工程师协助支持，并支持做硬件架构的评审。硬件安全架构应尽量满足模块化、适当的粒度水平、简单性等特征。在硬件架构设计过程中，也可以参考ISO 26262第５部分中硬件架构的设计方法（Table1）。
图８－硬件架构设计原则
3. 软硬件接口列表（HSI）：
在硬件设计阶段，功能安全工程师还要协助硬件工程师完成软硬件接口列表的设计。在定义软硬件接口时，要考虑好以下的要素：
a. 存储器（RAM,ROM等）；
b. 总线接口（CAN, LIN等）；
c. 转换器 （A/D，D/A，ＰＷＭ）；
d. Ｉ/O口；
e. 看门狗（内狗，外狗）；
f. 多路转换器；
【注】：每家公司对HSI的责任划分也是不同的，有的可能要求系统工程师或者软件工程师主导HSI的定义。
图９：软硬件接口概览
4. 硬件安全分析：
功能安全工程师要协助硬件工程师进行硬件层面的安全分析，包括FMEA和FMEDA分析。
a. FMEA分析：硬件FMEA分析直接在系统FMEA分析的基础上继续对硬件组件进行分析就可以了。
b. FMEDA分析：FMEDA的计算，需要的输入比较多（如：安全目标，硬件失效率目标值，安全要求，安全架构，BOM表，Mission Profile，安全机制列表，SN29500的基础失效率等），有了这些输入就可以开始FMEDA的计算了，以检查所设计的硬件产品的三个指标值（SPFM，LFM，PMHF）是否满足相应ASIL等级的要求。
图10：硬件失效率度量指标值
软件开发设计
1. 软件安全要求开发：
与硬件开发类似，有了技术安全要求、系统需求和系统架构、硬件设计规范、软硬件接口列表和软件开发环境的输入后，功能安全工程师就可以协助软件需求工程师来开发软件安全要求了。软件安全要求一般来源于分配给软件的技术安全要求或者软件功能和特性的要求（如：能够安全执行相关功能，能够使系统达到或者维持安全状态的相关功能等）。
图11：软件层面的产品开发
2. 软件安全架构：
软件安全架构设计主要是软件架构师来负责，功能安全工程师协助支持，并支持做软件架构的评审活动。软件架构的设计要尽量满足一致性、简单性、可验证性、模块化、可维护性等特征。在软件架构设计中也可以参考ISO 26262第６部分中软件架构设计的方法（Table2, Table3 和Table４）。
图12：软件架构设计原则
3. 软件单元设计和实现：
软件单元设计与实现主要由软件开发人员负责，功能安全工程师能提供的支持相对有限。与软件架构设计类似，软件单元设计也应尽量满足一致性、可维护性、可验证性等特性。在软件单元设计和实现的活动中，也可以参考ISO 26262第６部分中软件单元设计的方法（Table5, Table6）。
图13：软件单元设计和实现的设计原则
4. 软件安全分析：
功能安全工程师要协助软件工程师完成软件的安全分析。与硬件相比，软件安全分析没有特定的方法，有的公司要求做软件FMEA分析；而有的公司觉得用FMEA的思路来做软件安全分析也并不是特别合适，这时候通常采用一种软件关键路径分析的方法来对软件进行安全分析（需要软件的动态架构和静态架构来支持分析）。
4
测试验证阶段
对于各个阶段的测试话题，由于很少有公司要求功能安全工程师去执行测试活动，这里只简单聊一聊各个阶段的测试以及功能安全工程师在测试验证阶段要做些什么。
在各个阶段的测试开始之前，功能安全工程师要主导ISO 26262方法的裁剪活动。功能安全工程师要跟系统、软硬件和相关测试工程师一起，完成对ISO 26262方法的裁剪，被裁剪掉的方法要给出充分合理的理由。（“＋＋“代表高度推荐该方法，一般不能裁剪掉；“＋”代表推荐该方法，如果有合理的理由可以进行裁剪；“ｏ”代表不推荐该方法）
系统测试验证
系统阶段的测试一般包含以下几种：
a) 系统功能测试：验证系统功能是否满足系统要求
b) 系统集成测试：验证组件之间的接口是否满足设计要求
c) DV测试：DV是设计验证，验证产品设计是否满足要求，其中DV测试又包含环境耐久测试、电磁兼容测试、电气特性测试
d) PV测试：PV是产品验证，主要验证产线上生产出来的产品是否符合要求。一般PV之后的产品，就具备了批量生产的资格了。
硬件测试验证
硬件阶段的测试一般比较关注硬件功能测试，也就是基于相关硬件需求的测试，以确认硬件电路设计与硬件需求是一致的。
软件测试验证
硬件阶段的测试一般包含以下几种：
a) 软件功能测试：验证软件实现是否与软件需求一致。
b) 软件单元测试：验证单元设计是否与单元设计需求规范一致。
c) 软件集成测试：验证集成的软件是否满足软件需求，以及软件组件之间的接口是否一致。
上述系统、硬件和软件层面的测试验证分别由系统、硬件和软件测试工程师来负责。功能安全工程师主要关注相关的测试结果是否都通过，测试覆盖度是否满足100％。如果有测试失败项，该测试会不会对产品的功能安全有影响。如果有失效项，复测结果如何。
【注】：通常故障注入测试会涵盖在功能测试里，所以这里没有单独把故障注入测试拎出来。对于有些产品，如果用到的ASIC有安全手册，也需要对裁剪后的安全机制进行故障注入测试，以确保实现的安全机制满足要求。
3
参考文献
[1] ISO 26262:2018, Part1
[2] ISO 26262:2018, Part2
[3] ISO 26262:2018, Part3
[4] ISO 26262:2018, Part4
[5] ISO 26262:2018, Part5
[6] ISO 26262:2018, Part6
[7] ISO 26262:2018, Part9
[8] SEMANTIC SCHOLAR search, A free, AI-powered research tool for scientific literature