下载掌阅APP，畅读海量书库
立即打开
【标准内容】
技术安全概念文档包括系统技术安全需求。
每个技术安全需求应与上一级的安全需求相关联（如通过交叉引用），可包含：
——其他技术安全需求；
——功能安全需求。
注： 采用恰当的需求管理工具可提高追溯性。
技术安全概念需求的实现应考虑可行性、无歧义性、一致性和完整性。
技术安全概念应考虑以下因素：
（1）所有安全目标和功能安全需求。
（2）所有相关规范、标准和法律法规。
（3）安全分析工具（FMEA、FTA等）的分析结果。在系统开发过程中，安全分析为技术安全概念提供迭代支持。
在系统设计过程中，技术安全概念的完整性不断迭代完善。为确保完整性：
（1）应指定技术安全概念的版本及有关基础来源的版本。
（2）应符合变更管理的要求（见GB/T38874.4—2020的第11章）。因此，技术安全需求应结构化与格式化，为修改过程提供支持。
（3）应对技术安全需求（见GB/T38874.4—2020的第6章）进行复查。
技术安全概念应考虑寿命周期的所有阶段（包括生产、用户操作、维护和报废）。
索引：本节标准内容源自GB/T38874.3—2020的5.4.2.1节。
【解析】
技术安全概念文档是GB/T38874中的一个重要概念。技术安全概念文档是一个关键的文档，指的是对功能安全进行详细说明和解释的文档。它包含所有相关的技术安全需求，旨在确保技术安全性能得到满足。该文档记录了系统设计和实现的技术安全需求，包括技术安全性能指标和设计规则。它还包含用于验证技术安全性能的测试计划和方法。假设有一个针对自动驾驶汽车的技术安全概念文档，在这个文档中可以包括下列内容。
（1）系统技术安全需求。例如，自动驾驶汽车在高速公路上行驶时，必须能够及时响应前方障碍物的出现并避免碰撞。
（2）技术安全性能指标。例如，自动驾驶汽车必须能够在特定时间内检测到障碍物，并在适当的时间内采取必要的措施，以避免碰撞。
（3）设计规则。例如，自动驾驶汽车必须采用先进的传感器和相应的控制系统，以实现高效的障碍物检测和避免碰撞。
（4）测试和验证方法。例如，汽车的技术安全性能可以通过仿真测试或在控制环境中进行测试来验证。
技术安全概念文档是功能安全管理过程中的重要文档，旨在确保整个软件开发和验证过程都能满足所需的技术安全性能要求。以上例子说明了技术安全概念文档的重要性和需要记录的关键信息。技术安全概念文档有助于确保系统设计和实现满足功能安全要求，并且有足够的数据来测试和验证系统的技术安全性能。
定义： 系统技术安全需求是指在GB/T38874中，对于一个特定的系统或子系统，需要满足的技术安全性能要求的详细描述。这些要求包括硬件、软件、通信和系统架构等方面，以确保系统的安全性能达到预期目标。
系统技术安全需求通常由系统设计人员或安全工程师编写，可以根据上级需求文档中的要求进行编写。系统技术安全需求应该是可测量的，并且应该根据系统的架构和特点进行描述。
例如，对于一辆汽车的制动系统，系统技术安全需求可能包括以下几方面。
（1）制动系统的实时性能要求，如踩制动踏板到制动器响应的时间要求。
（2）制动系统的可靠性要求，如制动系统故障率不超过特定的值。
（3）制动系统的通信安全要求，如制动信号与其他系统之间的安全通信要求。
（4）制动系统的环境安全要求，如对制动系统操作温度、湿度等环境条件的要求。
上述系统技术安全需求是确保制动系统的安全性能达到预期目标的关键因素，并且需要在整个软件开发和测试过程中进行跟踪与验证，以确保系统符合设计要求并满足预期的安全性能目标。
要求： 每个技术安全需求应与上一级的安全需求相关联。
每个技术安全需求应与上一级的安全需求相关联，以确保整个技术安全概念文档中的所有需求都能够追溯到顶级安全需求。例如，每个技术安全需求都应该与功能安全需求相关联，这些功能安全需求应该与系统安全需求相关联。这种上下级之间的关联性是非常重要的，因为它确保了整个系统的安全性能是整体的，而不是一堆没有联系的零散需求。
此外，采用恰当的需求管理工具可以提高追溯性。需求管理工具可以用来跟踪所有需求的实现情况，以确保它们在系统设计和实现中得到了满足。
需求追溯性是指能够追溯每个需求的来源、变更历史和与之相关的其他需求、设计元素、验证活动、测试用例等。在功能安全评估中，需求追溯性是非常重要的，因为它有助于确保系统整个安全寿命周期中的每个阶段都得到了充分的考虑，从而提高了系统的安全性和可靠性。例如，需求跟踪矩阵可以用于跟踪功能安全需求和技术安全需求的实现情况，以确保它们都得到了满足。通过采用这种工具，系统开发团队更好地管理需求，以确保整个系统的安全性能得到满足。
技术安全概念需求的实现应考虑可行性、无歧义性、一致性和完整性，以确保技术安全概念能够准确地反映功能安全的要求，并且能够在实际系统设计中有效地实现。
（1）可行性：技术安全概念需求应该是可实现的。这意味着在制定技术安全概念时，必须考虑技术限制、可用技术、成本和时间等实际情况。例如，在汽车中实现碰撞检测系统，需要考虑传感器的位置和类型、传感器数据的处理方式及适当的算法等因素。
（2）无歧义性：技术安全概念需求应该是明确的，不会产生歧义或误解。为了实现这一点，技术安全概念需求应该采用清晰的术语和定义，避免使用不确定的或模糊的语言。例如，“可靠性高”可能会有多种不同的解释，因此更好的描述方式是使用具体的指标和目标。
（3）一致性：技术安全概念需求应该与功能安全概念需求相一致。这意味着技术安全概念应该能够满足功能安全概念中所要求的安全性能指标和目标，并与之相协调。例如，功能安全概念需要实现的安全性能级别为ASIL C，那么技术安全概念应该相应地进行设计和实现。
（4）完整性：技术安全概念需求应该涵盖所有的功能安全概念需求。这意味着技术安全概念应该覆盖所有的系统组件和功能，并与功能安全概念需求相对应。例如，在开发一款汽车控制系统时，技术安全概念需要涵盖所有的汽车控制功能，以确保系统能够满足所有的功能安全要求。
技术安全概念应考虑以下因素。
（1）所有安全目标和功能安全需求：技术安全概念应该包括所有安全目标和功能安全需求，以确保系统能够达到设计的安全水平。这些安全目标和功能安全需求应该在系统的整个寿命周期中得到追踪与更新。例如，在汽车行业中，一个安全目标是确保车辆不会在行驶过程中突然失去控制，因此该安全目标具有相应的功能安全需求，如ESC系统等。
（2）所有相关规范、标准和法律法规：技术安全概念应该考虑所有相关规范、标准和法律法规，以确保系统的安全性符合行业标准和法律法规要求。例如，在医疗设备领域，ISO 13485是一个重要的标准，它规定了医疗设备制造商必须遵守的质量管理要求。
（3）安全分析工具（FMEA、FTA等）的分析结果：技术安全概念应该基于安全分析工具的分析结果进行开发，以便发现和解决潜在的安全问题。例如，在铁路交通领域中，一列火车可能会出现的安全问题可以通过FMEA进行分析，以识别潜在的危险和开发必要的安全措施。在系统开发过程中，安全分析为技术安全概念提供迭代支持。通过不断地分析和改进技术安全概念，可以确保系统的安全性能符合预期并满足所有的安全要求。
总之，GB/T38874中的技术安全概念是实现功能安全的重要组成部分。技术安全概念文档包括系统技术安全需求。技术安全概念文档描述了实现功能安全的技术安全需求，其实现应考虑可行性、无歧义性、一致性和完整性。每个技术安全需求应与上一级的安全需求相关联，并包含其他技术安全需求和功能安全需求。采用恰当的需求管理工具可以提高追溯性，确保技术安全需求实现的完整性和一致性。
在系统设计过程中，技术安全概念的完整性不断迭代完善，为确保其完整性应进行的活动如下。
（1）应指定技术安全概念的版本及有关基础来源的版本：在技术安全概念的制定过程中，需要明确技术安全概念的版本及有关基础来源的版本。这样可以确保在技术安全概念修改和迭代过程中，能够准确追溯各个版本之间的变更情况和基础来源。例如，在汽车行业中，车辆的功能安全设计需要遵循ISO 26262，对于每个开发阶段都需要明确系统版本号和所基于的ISO 26262的版本号。
（2）应符合变更管理的要求：技术安全概念的制定和迭代过程需要符合变更管理的要求，确保技术安全需求的修改和变更得到记录与跟踪，包括变更的原因、影响范围、验证结果等。例如，在航空航天领域中，需要根据AS9100的要求，对技术安全需求进行变更管理。
（3）应对技术安全需求进行复查：为确保技术安全概念的完整性，需要对其进行复查，包括内部复查和外部复查。内部复查主要由软件开发团队进行，通过对技术安全需求进行审核和评审，检查技术安全概念的准确性和完整性。外部复查由第三方机构或审核团队进行，通过对技术安全需求进行审查和验证，确认技术安全需求的有效性和适用性。例如，在铁路交通领域中，需要根据EN 50126的要求，对技术安全需求进行复查。
总体而言，在系统设计过程中，技术安全概念的完整性至关重要。为确保技术安全概念的完整性，应进行以下活动：①版本控制，对技术安全概念及有关基础来源进行版本控制，以确保不同版本之间的一致性；②变更管理，根据变更管理的要求，对技术安全需求进行结构化和格式化，以支持修改过程的管理和控制；③复查，对技术安全需求进行复查，以确保技术安全概念的准确性和完整性。通过上述活动，可以有效保证技术安全概念的完整性，从而提高系统设计的安全性和可靠性。
技术安全概念在系统的整个寿命周期的所有阶段都应该被考虑到，包括生产、用户操作、维护和报废等阶段。在每个阶段，都需要对技术安全概念进行评估和验证，以确保系统在该阶段的安全性和可靠性。
（1）在生产阶段，技术安全概念需要考虑制造和装配过程中的安全性，如工作场所安全、作业指导书的正确性、检验和测试的有效性等。此外，还需要考虑制造和装配过程中可能出现的故障和问题，以及如何应对这些故障和问题。
（2）在用户操作阶段，技术安全概念需要考虑如何确保系统在正常使用时的安全性和可靠性，包括用户界面的设计、安全使用指南、预防意外事件发生的措施等。此外，还需要考虑如何应对用户犯错或不正确使用系统时可能出现的问题。
（3）在维护阶段，技术安全概念需要考虑如何确保系统在维修与保养时的安全性和可靠性，如维修流程的安全性、操作手册的正确性、维修工具和设备的可靠性等。
（4）在报废阶段，技术安全概念需要考虑如何处理废弃物和剩余材料，以及如何确保废弃物和剩余材料不会对环境及人体造成危害。
技术安全概念需要贯穿系统的整个寿命周期，涵盖各个阶段，并考虑每个阶段可能出现的问题和挑战，以确保系统在整个寿命周期内的安全性和可靠性。
【标准内容】
概述：
技术安全概念应包括满足SRP/CS设计要求的软硬件安全需求，并应符合本书2.2.2.1节中的规定。
状态和时间：
应规定所有的工作状态下SRP/CS的行为、组件以及其接口。工作状态包括：
——启动；
——正常运行；
——停机；
——复位后重启；
——合理可预见的异常运行状态（如降级的运行状态）。
特别地，应准确描述失效行为及其响应，也可包含附加的应急运行功能。
技术安全概念应为每个功能安全需求规定一个安全状态：转移到安全状态、保持安全状态。应特别规定关闭SRP/CS是否立即进入安全状态，或者仅通过可控停机操作才能进入安全状态。
技术安全概念应规定每个功能安全需求从出现错误至进入安全状态的最大持续时间（响应时间）。技术安全概念中应规定每个子系统和子功能的响应时间。
如果直接停机不能进入安全状态，则应确定一个时间段。在此期间，所有子系统和子功能应执行应急操作功能。在技术安全概念中，应记录应急操作功能。
索引：本节标准内容源自GB/T38874.3—2020的5.4.2.2.1节和5.4.2.2.2节。
【解析】
技术安全概念应包括软硬件安全需求，以确保满足系统安全相关的SRP/CS设计要求。
在GB/T38874中，技术安全概念文档包括系统技术安全需求，其中系统技术安全需求涵盖软硬件方面的安全要求。在硬件方面，系统技术安全需求可能涉及电路设计的电气安全要求、EMC要求、接口安全性能要求等；在软件方面，系统技术安全需求可能涉及软件设计的安全性能要求、输入输出处理的安全要求、存储和保护敏感数据的安全要求等。
在实践中，为了确保满足SRP/CS设计要求，需要在技术安全概念文档中明确指定软硬件安全需求，并在开发过程中跟踪和验证这些需求的实现。这可以通过使用一系列技术手段来实现，如使用安全设计方法和工具、开展相关的安全测试和验证等。
在规定的工作状态下，需要考虑系统在不同状态下的行为和响应，以确保系统的安全性。在通常情况下，工作状态包括启动、正常运行、停机、复位后重启，以及合理可预见的异常运行状态（如降级的运行状态）。对于每个工作状态，需要准确描述系统的行为和响应，以保证系统的安全性和可靠性。
在技术安全概念规范的状态和时间方面，应规定所有的工作状态下SRP/CS的行为、组件以及其接口，工作状态包括以下几个。
（1）启动：在启动状态下，系统处于启动过程，还未达到正常运行状态，此时系统可能存在启动失败、启动延迟、启动流程不完整等风险。因此，在技术安全概念中，需要明确系统启动时的安全需求，如启动时的自检程序、初始化流程等。例如，在汽车中，系统在启动状态下需要完成诊断检查、设备初始化、车速检测等流程，确保系统正常运行。
（2）正常运行：在正常运行状态下，系统按照预定的功能和安全性能要求工作，此时需要满足系统的功能安全和技术安全需求。在技术安全概念中，需要明确系统在正常运行状态下的安全需求，如实时监控系统状态、安全性能的保持等。例如，在工业自动化系统中，系统在正常运行状态下需要对输入输出信号进行实时监控，确保信号的正确性和可靠性。
（3）停机：在停机状态下，系统暂停了正常运行状态下的功能和安全性能，此时需要满足停机状态下的安全需求，如保持安全状态、防止未授权人员操作等。例如，在电力系统中，当发生故障或需要维护时，系统需要停机，此时需要防止未授权人员操作，确保系统处于安全状态。
（4）复位后重启：在复位后重启状态下，系统重启并回到正常运行状态，此时需要满足系统的安全需求，如启动自检、清除错误状态等。例如，在航空电子设备中，当发生故障或错误时，系统需要重启，此时需要启动自检、清除错误状态，确保系统正常工作。
（5）合理可预见的异常运行状态（如降级的运行状态）：在合理可预见的异常运行状态下，系统可能出现降级状态或功能的部分失效，此时需要满足系统在此状态下的安全需求，如提供应急措施、减小危险等。例如，在飞行控制系统中，当飞机遭遇恶劣天气或其他突发事件时，系统可能出现降级状态，此时需要提供应急措施、减小危险，保障飞行安全。
应准确描述失效行为及其响应。失效行为是指组件在运行过程中出现的异常行为，如电子元件的短路或断路等。对于失效行为，系统需要及时检测并进行响应，以确保系统的安全性。此外，还需要考虑附加的应急运行功能，以应对一些特殊情况，如紧急制动或突发事件等。
因此，在技术安全概念规范中，需要对所有工作状态下SRP/CS的行为、组件以及其接口进行准确描述，以确保系统在各种情况下的安全性和可靠性。
技术安全概念应为每个功能安全需求规定一个安全状态，以确保系统在出现故障或错误时仍然能够维持安全性。安全状态通常包括两种类型：转移到安全状态和保持安全状态。
转移到安全状态是指系统在检测到故障或错误时，会采取措施切换到安全状态，以避免潜在的危险或损害。例如，当汽车的ABS检测到车轮正在打滑时，会切换到安全状态以避免车辆失控。
保持安全状态是指系统在出现故障或错误时，仍然能够保持安全性，而不是立即转移到安全状态。例如，当电梯故障时，即使不能移动，仍然可以保持安全状态，以确保人员安全。
技术安全概念应特别规定关闭SRP/CS是否立即进入安全状态，或者仅通过可控停机操作才能进入安全状态。这是因为在某些情况下，直接关闭系统可能会导致更高的风险和更大的损害，而通过可控停机操作可以更好地控制系统进入安全状态的过程。
此外，技术安全概念还应规定每个功能安全需求从出现错误至进入安全状态的最大持续时间，也称为响应时间。这是为了确保系统在发生故障或错误时，能够及时采取措施，从而避免或最小化损害。例如，当飞机发生故障时，响应时间必须足够短，以确保飞机能够及时采取措施，避免事故发生。
如果直接停机不能进入安全状态，则应确定一个时间段。在此期间，所有子系统和子功能应执行应急操作功能。这些应急操作功能应在技术安全概念中记录，并确保它们能够在出现故障或错误时得到有效执行。例如，当核电站发生故障时，应急操作功能包括紧急关闭反应堆，以避免核泄漏。
总之，技术安全概念中规定的安全状态、响应时间和应急操作功能等都是为了确保系统在发生故障或错误时能够及时采取措施，以避免或最小化损害。
【标准内容】
应对安全架构及其子组件进行描述。应特别规定所采取的技术性措施。技术安全概念应描述以下组件（如适用）：
——传感器系统，分别记录每个物理参数；
——混合数字和模拟输入输出单元；
——处理单元，分别说明每个算术单元/离散逻辑单元；
——执行系统，分别说明每个执行器；
——显示器，分别说明每个指示单元；
——各种机电组件；
——组件间的信号传输；
——系统外部与SRP/CS间的信号传输；
——电源。
应规定SRP/CS组件间的接口、机器中与其他系统和功能间的接口以及用户接口。
应规定SRP/CS的限定条件及边界条件，这特别适合寿命周期各阶段所有环境条件的极值。
索引：本节标准内容源自GB/T38874.3—2020的5.4.2.2.3节。
【解析】
在技术安全概念规范的安全架构、接口和边界条件方面，需要对SRP/CS的各个组件进行描述，应规定SRP/CS组件间的接口、机器中与其他系统和功能间的接口以及用户接口。这些描述需要包括以下内容。
（1）传感器系统：需要分别记录每个传感器系统的参数，包括传感器的型号、品牌和精度等。
（2）混合数字和模拟输入输出单元：对于每个输入输出单元，需要详细说明其输入和输出的电气特性与工作方式，以及与其他组件的接口。
（3）处理单元：需要说明每个算术单元和离散逻辑单元的工作原理与性能参数。
（4）执行系统：需要说明每个执行器的类型、工作原理和性能参数。
（5）显示器：需要说明每个指示单元的类型、显示内容和精度等。
（6）各种机电组件：需要说明每个机电组件的型号、品牌和精度等。
（7）组件间的信号传输：需要描述各个组件之间的信号传输方式，包括信号的类型、数据传输速率和传输方式等。
（8）系统外部与SRP/CS间的信号传输：需要描述系统外部与SRP/CS间的信号传输方式，包括接口类型、通信协议和数据格式等。
（9）电源：需要说明电源的类型及电压、电流和容量等参数。
在此基础上，需要规定SRP/CS组件间的接口、机器中与其他系统和功能间的接口以及用户接口，以确保组件之间的正确连接和通信。同时，需要规定SRP/CS的限定条件及边界条件，以确保系统在各种环境条件下都能正常工作。这些限定条件及边界条件包括机器的工作环境、电源电压范围、通信距离、数据传输速率和通信协议等。
总之，技术安全概念规范的安全架构、接口和边界条件是技术安全概念的重要内容。这一方面的规范应对安全架构及其子组件进行描述，并特别规定所采取的技术性措施。其中需要描述的组件包括传感器系统、混合数字和模拟输入输出单元、处理单元、执行系统、显示器、各种机电组件、组件间的信号传输、系统外部与SRP/CS间的信号传输、电源。同时，应规定SRP/CS组件间的接口、机器中与其他系统和功能间的接口以及用户接口。还应规定SRP/CS的限定条件及边界条件，这特别适合寿命周期各阶段所有环境条件的极值。这些规范可以为技术安全概念的设计和实现提供有力支持。