下载掌阅APP，畅读海量书库
立即打开
4.2.1 A functional safety plan shall be drawn up and documented for each SRECS design project,and shall be updated as necessary.The plan shall include procedures for control of the activities specified in Clauses 5 to 9.
NOTE1 The content of the functional safety plan should depend upon the specific circumstances,which can include:
-size of project;
-degree of complexity;
-degree of novelty of design and technology;
-degree of standardization of design features;
-possible consequence(s) in the event of failure.
In particular the plan shall:
a) identify the relevant activities specified in Clauses 5 to 9.
b) describe the policy and strategy to fulfil the specified functional safety requirements.
c) describe the strategy to achieve functional safety for the application software,development,integration,verification and validation.
d) identify persons,departments or other units and resources that are responsible for carrying out and reviewing each of the activities specified in Clauses 5 to 9.
e) identify or establish the procedures and resources to record and maintain information relevant to the functional safety of a SRECS.
NOTE2 The following should be considered:
-the results of the hazard identification and risk assessment;
-the equipment used for safety-related functions together with its safety requirements;
-the organization responsible for maintaining functional safety;
-the procedures necessary to achieve and maintain functional safety (including SRECS modifications).
f) describe the strategy for configuration management (see 9.3) taking into account relevant organizational issues,such as authorized persons and internal structures of the organization.
g) establish a verification plan that shall include:
-details of when the verification shall take place;
-details of the persons,departments or units who shall carry out the verification;
-the selection of verification strategies and techniques;
-the selection and utilization of test equipment;
-the selection of verification activities;
-acceptance criteria;and
-the means to be used for the evaluation of verification results.
h) establish a validation plan comprising:
-details of when the validation shall take place;
-identification of the relevant modes of operation of the machine (e.g.normal operation,setting);
-requirements against which the SRECS is to be validated;
-the technical strategy for validation,for example analytical methods or statistical tests;
-acceptance criteria;and
-actions to be taken in the event of failure to meet the acceptance criteria.
NOTE3 The validation plan should indicate whether the SRECS and its subsystems are to be subject to routine testing,type testing and/or sample testing.
4.2.1 对于每个SRECS设计项目，都应起草功能安全计划，并形成文档，必要时应及时更新。该计划应包括第5章至第9章规定的运行控制程序。
注1 ：功能安全计划内容应根据具体情况而定，其中包括：
——项目规模；
——复杂程度；
——设计和技术新颖程度；
——设计特点标准化程度；
——失效的可能后果。
该计划尤其应注意下列各项：
a）确定第5章至第9章规定的有关活动。
b）描述为满足规定的功能安全要求而采取的方针和策略。
c）描述为实现应用软件、开发、集成、验证和确认的功能安全策略。
d）确定第5章至第9章中规定的对执行和检查各项工作负责的人员、部门或者其他单位和资源。
e）确定或建立相关程序和资源以便记录和维护同SRECS功能安全相关的信息。
注2 ：应考虑下列因素：
——危险识别和风险评价的结果；
——用于安全相关功能及其安全要求的设备；
——负责维护功能安全的机构；
——达到和保持功能安全（包括SRECS修改）所需的程序。
f）描述考虑相关机构问题时的配置管理（见9.3）策略，如被授权的人及该机构的内部结构。
g）建立验证计划，应包括：
●进行验证的细节；
●执行验证的人员、部门或单位的详细情况；
●验证策略和技术的选择；
●试验设备的选择和使用；
●验证活动的选择；
●验收准则；
●用于评估验证结果的方法。
h）建立确认计划，其中包括：
●进行确认的细节；
●机器操作有关模式（如正常操作、设置）的确定；
●对照受验证的SRECS的要求；
●适用于确认的技术策略，如分析方法或统计试验；
●验收准则；
●出现失效时采取的行动，以满足验收要求。
注3 ：确认计划应指出SRECS及其子系统是否进行常规测试、型式测试和/或抽样测试。
标准条款4.2.1对机器人研制厂商提出了编写功能安全计划的要求。
功能安全对于机器人而言是一个重要的特性，而且功能安全特性的正确实现往往比机器人本身的功能、性能实现更具有挑战性。要完成这个挑战性任务，保证机器人的功能安全特性符合项目要求，第一步就是投入足够的力量，做好功能安全计划。
机器人控制系统功能安全计划就是机器人控制系统软件项目功能安全相关活动的指南，涉及标准第5章至第9章的内容。但是这些标准条款却很难落地。对于不同的具体项目，要求不同、资源不同，所以在标准条款4.2.1中，总体上指出了决定功能安全计划内容的关键因素，它们分别是项目规模、复杂程度、设计和技术新颖程度、设计特点标准化程度、失效的可能后果。
（1）一般来说，项目规模越大，功能安全计划的内容应越充分。项目规模大，项目内部的模块、环节就相应增多。影响控制系统软件功能安全水平的因素越多，控制系统软件面临的风险就越多，就要求项目组在项目的启动阶段，投入更多的精力，对控制系统软件进行全面的风险评估和功能安全失效分析。对于小型的项目，控制系统软件的结构简单、逻辑清晰，面临的风险也相对较低，功能安全计划的内容可以进行适当的精简。有人认为，功能安全计划被精简不会影响控制系统软件功能安全水平。其实，我们不是为了编制计划而编制计划。编制计划，为的是后面更好地执行计划，推进项目进度。在功能安全计划要素不遗漏的情况下，在项目组成员能够清晰执行计划的前提下，对计划进行裁剪，不但不会影响功能安全水平，反而能够提升计划的可执行性。对于小型项目，功能安全计划要能做到“麻雀虽小，五脏俱全”。对于大型项目，功能安全计划要力求面面俱到，把系统的各个模块都纳入计划。
（2）系统的复杂程度决定了系统功能安全设计风险和项目实现所面临的困难。复杂程度越高，越需要编制周全的功能安全计划，并依据计划实施功能安全活动，保障系统的功能安全水平。
（3）旧的设计和技术经历了较长时间的考验，较充分地暴露了其所固有的缺陷、风险，并且人们已经具有处理这些缺陷、风险的丰富经验。而新设计、新技术缺乏较充分的实践验证，人们对新设计、新技术的缺陷、风险缺乏足够的处理经验。因此，对于采用新设计、新技术的系统，其功能安全风险比采用旧设计、旧技术的要高。对于功能安全要求高的项目，需要编制更详细的功能安全计划来降低新设计、新技术所带来的功能安全风险。
（4）对于设计特点标准化程度高的系统，功能安全需求被分解到系统的各个子模块中，设计难度降低。而对于设计特点标准化程度低的系统，功能安全需求分解存在不合理、不到位的情况，即系统设计中存在较高的功能安全风险。因此，对于设计特点标准化程度低的系统，需要更详细的功能安全计划来保障。
（5）失效后果越严重，对系统的功能安全要求越高，这对系统的设计、测试提出了更高的要求。因此，对于失效后果严重的系统，要求功能安全计划覆盖更全面、可操作性更强。
标准条款对功能安全计划的内容提出了明确的要求。
（1）确定标准第5章至第9章中规定的有关活动。具体要求将在相关章节中展开讲解，此处就不再赘述了。
（2）对为满足规定的功能安全要求而采取的方针和策略进行描述。此处应对功能安全目标进行合适的分解，总体思想是将大目标分解为小目标，将总目标分解为阶段目标。机械/工业机器人的功能安全目标，是由若干功能安全模块共同实现的。通常，机械/工业机器人的功能安全目标会分解到传感器（光电传感器、压力传感器、电磁传感器、视觉传感器等）、控制器和执行机构（伺服、减速器、限位器等）中实现。整体功能安全首先要确保各个相关模块的功能安全目标已经实现。在传感器、控制器和执行机构中，软件起到了功能安全核心作用。各个功能安全风险的动态识别、功能安全模块的状态，都需要由软件进行判别和处理。在功能安全计划中，要把软件的功能安全属性放在首要位置。确定软件方面的方针和策略，首先就是要区分软件开发的各个阶段。通常，软件开发会经历需求分析、概要设计、详细设计、软件编码、软/硬件联调等环节。产品投入市场后，软件还会经历版本升级的过程。因此，功能安全计划应结合软件开发定制不同阶段的活动与措施。另外，功能安全保障措施的实施需要比较高的人力和时间成本，不可能做到面面俱到，所以功能安全保障措施的实施要讲求策略，什么事情先做、什么事情后做要结合实际，写到计划中。一般建议，在需求分析、概要设计、详细设计阶段投入大量的资源，着力开展功能安全保障活动；在软件编码、软/硬件联调阶段，功能安全保障活动基本上与软/硬件的测试活动重合，可以灵活处理。
（3）对实现应用软件、开发、集成、验证和确认的功能安全策略进行描述。这里所讲的策略，指的是时间安排、工具使用等方面的策略。对于应用软件，能重用的尽量重用。早期的软件或软件模块，经历了长时间的实践考验，功能安全特性得到充分暴露，发生功能安全缺陷的风险比较低。在开发过程中，应尽量使用自动化辅助开发工具。自动化辅助开发工具可以为需求分析、概要设计、详细设计、软件编码提供有效的保障。在需求分析阶段，自动化辅助开发工具可以通过逻辑推理、形式化验证等手段，协助分析师更充分、全面地完成机械/工业机器人软件的需求分析工作。在概要设计和详细设计阶段，自动化辅助开发工具可以进行原型仿真，以高效、直观的方式，为设计师提供一个快速验证平台。在软件编码阶段，自动化辅助开发工具一方面能够生成规范的代码，另一方面能够协助程序员发现代码中的缺陷。因此，在功能安全计划中，可以明确在哪些环节应用哪种工具、协助人们完成哪些工作。在集成、验证方面，功能安全计划中要明确对象的范围。在最理想的情况下，每一轮的集成都应该开展测试活动，以确保集成是成功的，但实际上这是不可行的，所以要根据风险的大小，确定集成和验证的层次、范围。而在确认方面，首先计划中要详细列明确认过程中的各项条款。判定一款机械/工业机器人控制系统软件是否通过最终验收时，需要依据确认条款，逐条进行确认。
（4）确定标准第5章至第9章中规定的对执行和检查各项工作负责的人员、部门或者其他单位和资源。这表示对整个功能安全保障活动的资源进行安排和调配。这里讲的资源，包括人力资源、场地资源、设备资源、软件资源、时间资源等。
（5）确定或建立相关程序和资源以便记录和维护同SRECS功能安全相关的信息。具体而言，功能安全计划中要提供一系列的表格模板，以纸质或电子形式记录和维护SRECS功能安全相关信息，并且要有一套明确的制度，确保信息内容的真实性和有效性，明确功能安全保障活动的各个参与者的角色、任务和权限。
标准还强调要考虑以下因素。
①危险识别和风险评价的结果。功能安全计划中应列举机械/工业机器人的所有危险源和风险源，而且危险源和风险源应有量化指标，并进行优先级排序。
②用于安全相关功能及其安全要求的设备。确定机械/工业机器人中的功能安全核心模块，以及在功能安全保障措施实施过程中使用的软件和硬件信息。
③负责维护功能安全的机构。功能安全计划需要以书面形式确定功能安全维护的责任与分工。
④达到和保持功能安全（包括SRECS修改）所需的程序。建立一套合适的流程，并明确各个角色在流程中的职责与工作内容，确保各项措施能够有效执行。
（6）描述考虑相关机构问题时的配置管理策略。详细内容在标准条款9.3中，我们会在本书的相关章节论述配置管理策略的具体内容。
（7）建立验证计划，并给出验证计划的总体框架。
①进行验证的细节。验证细节，即验证过程的具体内容，应描述清楚验证的对象、采取的主要步骤与方法、使用的辅助工具。这部分内容，是验证活动实施的重要指引，约束验证活动的执行者编制用例。考虑到功能安全验证团队成员技术水平的差异性，这部分内容应具有较高的可读性和可操作性，保证所有成员都能够准确无误地理解全部验证活动内容。
②执行验证的人员、部门或单位的详细情况。这部分内容主要是明确验证活动的执行人员信息，确定验证工作由哪个部门或单位实施。
③验证策略和技术的选择。依据被测对象的重要程度、复杂程度、验证资源的充裕程度，可从验证的过程、范围、次数等方面，选择不同的验证策略，如整体验证、按模块验证、一次性验证、分阶段验证等。而验证技术的选择，要符合被测机械/工业机器人的实际情况，主要的技术包括仿真、故障注入、数据采集等。
④试验设备的选择和使用。验证计划应明确验证活动中的环境构成，以清单形式列举验证过程中需要使用的全部试验设备，并记录试验设备的型号、厂商、序列号、有效期等信息；绘制验证环境图，明确试验设备间的连接方式，描述验证环境中各个设备的主要功能。
⑤验证活动的选择。根据功能完整性等级的不同，SIL1到SIL4所要求的验证活动是有所区别的。因此，在验证计划中，应明确验证活动的选择。
⑥验收准则。验证计划中，应明确通过验收的准则。例如，“验证过程中发现的问题应全部归零”“验证过程中发现的功能安全缺陷不得大于某个值”。
⑦用于评估验证结果的方法。常用的评估方法有统计法、对比法。统计法通过对验证过程中的问题按照等级、类型进行统计获得分布信息，以及通过一定的加权计算得到一个表征机械/工业机器人控制系统软件功能安全水平的数值，来衡量机械/工业机器人的功能安全水平。对比法则通过与其他品牌或其他型号的机械/工业机器人进行对比，来了解被测机械/工业机器人的功能安全水平。
（8）建立确认计划。对于验证和确认，从中文角度看，两者的含义很相似，但实际上两者的内涵是不一样的。验证是检验机械/工业机器人控制系统软件的实现是否符合标准、规范等的要求。在时间维度上，验证要考察软件开发的全过程，包括需求分析、概要设计、详细设计、软件编码、软/硬件联调等。而确认，则是检验机械/工业机器人控制系统软件是否满足既定的目标要求。针对功能安全，确认是检验机械/工业机器人控制系统软件是否实现了全部的功能安全需求，并且能够经受一定的考验。
对于确认计划，其内容包括：
①进行确认的细节。确认细节，即确认过程的具体内容，应描述清楚验证的对象、采取的主要步骤与方法、使用的辅助工具。这部分内容是确认活动实施的重要指引，约束确认活动的执行者编制用例。考虑到功能安全确认团队成员技术水平的差异性，这部分内容应具有较高的可读性和可操作性，保证所有成员都能够准确无误地理解全部确认活动内容。
②机器操作有关模式（如正常操作、设置）的确定。明确确认过程中，机械/工业机器人的各种可用工作模式，如正常工作、自检、维护等。因为机械/工业机器人在不同的模式下会开放不同的功能。而对于用户，不一定全部模式都需要使用。例如，需要专业人员操作的维护模式、系统升级模式等，是禁止用户使用的，因此在确认计划中，需要明确。
③对照受验证的SRECS的要求。确认计划应以列表形式，形成SRECS的要求与确认活动的追逐关系。通过列表方式一一对照，保证确认活动覆盖全部的SRECS要求。
④适用于确认的技术策略，如分析方法或统计试验。如果采取分析方法，则应描述清楚分析的对象、范围及采用的方法，如故障树分析、危险分析、数值仿真等。如果采用统计试验，则应确定样本的大小、采样的次数等具体信息。
⑤验收准则。确认计划应明确本次确认活动的通过准则。一般要求全部确认活动都正确实施，没有发现问题或者问题已经归零，才能通过。而对于特定的情况，使用特殊的通过准则，应该在计划中进行明确。
⑥出现失效时采取的行动，以满足验收要求。在确认过程中，若发现机械/工业机器人控制系统软件存在失效的情况，则应该填写相关的问题记录表，由开发人员、质量保证人员、用户等多方共同进行问题确认，约定问题归零的期限。开发人员应在约定期限内完成整改，并通知确认活动的执行人开展回归工作。
此外，标准还注明确认计划应指出SRECS及其子系统是否进行常规测试、型式测试和/或抽样测试，即要根据被测对象的重要等级、复杂程度、人力资源、时间资源，确定确认过程所选取的测试方式，并以书面形式确定。