Functional safety, part 4 of 7. Management and evaluation processes

A whole hub is dedicated to security in the Habré, and perhaps no one really thinks about what is embedded in the concept of security, and so everything is clear: information security. However, there is another side to safety, the safety associated with risks to human health and life, as well as the environment. Since information technologies themselves do not pose a danger, they usually speak of a functional component, that is, of security associated with the proper functioning of a computer system. If information security has become critical with the advent of the Internet, then functional security has been considered before the advent of digital control, because accidents have always occurred.



This article continues the series of publications on functional safety.

')

In this article, quite abstract requirements for the management of functional safety are interpreted for implementation in workflows. This information has been verified and polished in the practice of several certification projects.

Process engineering - is it boring or not? That process allows you to scale IT-business. I personally observed how the introduction of processes into development led to serious professional growth, both for performers and for the entire company. Conversely, the “gags” and the so-called “inexpediency” of introducing well-structured processes indicated immaturity and other serious problems.

So…



The previous article examined the structure of functional safety requirements (see Figure 1). Now we will focus on two aspects: functional safety management (Functional Safety Management) and functional safety assessment (Functional Safety Assessment).







Figure 1. Structure of IEC 61508 requirements

Functional Safety Management Plan

The functional safety management processes are largely consonant with the Project Management (PM) and Capability Maturity Model Integration (CMMI) processes.



Consider how functional safety management can be organized to meet the requirements of IEC 61508 and other related standards (IEC 61511, IEC 62061, ISO 26262, EN 50129, IEC 62304, etc.).



Such requirements are contained in clause 6, which is included in IEC 61508-1,2,3. The bulk of the requirements are presented in IEC 61508-1; in IEC 61508-2 there is only a reference to part 1, in IEC 61508-3 there is an addition in the part of software configuration management.



Now we will try to understand these requirements and the actions necessary to meet these requirements. In practice, it is best to develop a special document for this purpose - the Functional Safety Management Plan (FSMP). Such a plan will include several areas:

- Human Resource Management (Human Resource Management);

- configuration management (Configuration Management);

- selection and evaluation of development tools (Tools Selection and Evaluation);

- verification and validation (Verification and Validation);

- documentation management (Documentation Management);

- functional safety assessment.



All these points are discussed below in the relevant sections of the article. Their peculiarity lies in the fact that since each of the areas is a rather extensive, dynamic and partially autonomous process from others, it is recommended to develop and maintain their own separate documents (plans and reports) for each of them. In FSMP, it makes sense to leave the fundamental moments, without details.



In addition, the FSMP should contain the following sections (they are either fairly simple or fall outside the scope of this publication and will be considered in a planned publication on the life cycle description):

- The project policy and strategy (Project Policy and Strategy) is a rather declarative description of how and why the project goals will be achieved; in fact, it is possible to summarize the main provisions of the FSMP in this part;

- Suppliers Management includes interaction with suppliers of products and services that affect the provision of functional safety; this requirement came from the quality management system (ISO 9001); in terms of Project Management, an analogue is procurement management; IEC 61508 requires suppliers to have a quality management system; if suppliers have an ISO 9001 certificate, then there are no problems (and vice versa);

- information security (Security); IEC 61508 only casually speaks about this important property, which, of course, does not mean that this aspect is not paid attention to; these properties are described in other standards, and certification for their requirements is a separate process; as regards the process component considered here, it at least does not contradict the requirements for the information security management system (for example, certified according to ISO 27000);

- the functional safety life cycle should be described in stages in the FSMP; We will look at this component in a separate publication, as well as the process of Requirement Tracing adjacent to it.



Thus, the considered structure of FSMP is presented below in the form of Mind Maps.







Figure 2. Structure of a Functional Safety Management Plan (FSMP)



As already mentioned, many of the provisions in the management of functional safety overlap or are directly borrowed from project management. In addition, the application of project management is recommended in IEC 61508, as one of the methods of protection against systematic failures. Therefore, such tools as project charter, project plan based on WBS, Action and Bug Trackers, etc. warmly welcome and recommended. I will dwell on what should be done according to the requirements of the standard.

Human Resource Management

In principle, if the company has already applied the Project Management methodology (PMBOOK) or something similar (for example, CMMI), then, as a rule, nothing special needs to be done in this area. IEC 61508 requires pragmatic actions:

- appoint responsible persons to perform all necessary actions; since it also speaks of the need to coordinate actions related to the provision and evaluation of functional safety, it is advisable to appoint a so-called Functional Safety Coordinator (or you can also assign such functions to the project manager);

- define communication procedures between project officials, including outside parties;

- develop all necessary procedures that would block all areas listed in the FSMP;

- to organize the necessary training of personnel, ensuring the maintenance of competencies at the required level.



Based on the foregoing (as well as from personal experience), the main tools for personnel management in such projects are the org chart (Organizational Chart) and the competence matrix (Competency Matrix).

For detailed personnel management planning, we are developing an appropriate Human Resource Management Plan. Note that this plan does not apply to the organization as a whole, but only to the participants of a certified product development project (software or system) important to security. It should contain (see Figure 3):

- organizational chart of the project with a description of project roles;

- a list of project participants indicating project roles and responsibilities for planning and performing work at various stages of the life cycle;

- a competence matrix and conclusions about the sufficiency or lack of competence of the appointed performers (i.e., what knowledge and skills are required for a particular project role and to what extent a particular employee corresponds to them); Here the question may arise: “how can people with insufficient competencies be appointed?”; in the real world, however, the lack of resources, primarily human, is always observed; The positive news is that, in the event of a non-critical lack of competence, many performers can be taught the missing skills and knowledge;

- personnel training activities aimed at achieving and maintaining the above-mentioned competences that are critical for the implementation of the project; training plans and reports should be documented;

- communication plan of the project participants;

- a sheet with the signatures of personnel, indicating the familiarization with this plan.







Figure 3. Structure of the Human Resource Management Plan

Configuration Management

This direction is also quite well-known and methodically worked out, since it overlaps with PMBOOK and CMMI. In terms of functional safety, change management (Change Control) and the implementation of software and hardware modifications, including decommissioning, are also included in configuration management. The analysis of hazardous events also falls into this area, since various incidents are an input for making changes. Also, many useful provisions can be gleaned from the IEEE 828 Standard for Software Configuration Management Plan and, of course, from the blogs of the authors of Habr, for example, “Notes of a retired siemschik” from @Aguary .



When defining Configuration Items in the context of functional safety, it is important to understand that they include not only familiar source codes and builds of program code, but much more: development and testing tools (about them later), a full set of design, user-defined and any other relevant documentation (this is also slightly lower), including the design documentation, according to which all mechanical, electrical and electronic components are manufactured (see Figure 4).







Figure 4. Typical Configuration Items



Such a structure can serve as the basis for the project repository. Documents and tools will be explained in more detail below.



Configuration management is directly dependent on the tools used, but some general points that need to be included in the Configuration Management Plan (Configuration Management) can be identified, such as (see Figure 5):

- the roles and responsibilities of project participants in the configuration management process; of the key project participants, a configuration and change management team should be organized with the involvement of all those whose opinion is important to consider when making changes;

- an approach to planning and maintaining the configuration management process;

- the resources of the configuration management process, first of all, the tools used (SVN, Git, etc.);

- the procedure for the identification of all components of the Configuration (Configuration Items) and the formation of basic versions (baselines);

- the procedure for applying tools to control the versions of software and hardware components of the product and to account for their status;

- procedure for accessing configuration components and backup storage;

- the procedure and frequency of configuration audits;

- the procedure for analyzing and eliminating the identified defects, including those found during operation (this is one of the possible inputs for the next item - Change Control);

- A procedure for controlling changes (Change Control), including analyzing the impact of changes (Impact Analysis) and checking the correctness of changes.







Figure 5. Structure of a Configuration Management Plan (Configuration Management Plan)



The change control procedure is critical when implementing and certifying processes. For formalization, phased processing of change requests (Change Request) is usually used. The steps for making changes are presented below in the diagram (see Figure 6) and include:

Submit - the receipt of a request for a change, the cause may be any correction or refinement;

Approve - consideration and formal approval of the request; of course, the request may be rejected, then the subsequent steps are not executed;

Impact Analysis - analysis of the impact of the query on the functionality, safety, scope and cost of work, etc .; here it is determined not only the amount of development, but changes in documentation, testing and other checks related to verification and validation;

Implement - direct implementation of changes;

Verify - performance (possibly, step-by-step) of various kinds of verification checks in terms of the changes made;

Close - formally closing a change request.







Figure 6. Name control process (Change Control), based on processing change requests (Change Request)

Selection and evaluation of development tools (Tools Selection and Evaluation)

The selection and evaluation of tools (ICs) are closely related to functional safety management, although requirements are set out in IEC 61508-3 (7.4.4 Requirements for Support Tools, including Programming Languages).



Depending on the degree of influence on the final product (system and software), the tools are classified as follows:

- class T1 tools do not generate outputs that directly affect the executable code; This includes test and graphical editors, configuration management tools (those that do not directly generate code), Action & Bug Tracker;

- class T2 tools support testing and other types of verification (for example, static code analysis or test coverage completeness analysis); however, there is no direct impact on the executable code, however, a problem in the test tools may lead to errors in the software that may not be detected; This class should include not only software, but also software / hardware simulators of input / output signals; It should be noted that design tools for mechanical, electrical and electronic components (for example, printed circuit boards) can also be assigned to class T2;

- class T3 tools generate outputs that directly affect the executable code, these include translators and compilers, scripts to support assemblies and SCADA in terms of controller configuration.







Figure 7. Classification of generic tools for functional safety related projects.



Justifying the possibility of using compilers for functional security purposes is the greatest problem, since the requirements for them are such that all the functions affecting the generation of executable code must be fully tested. It’s hardly possible to get such information from a developer in private, and independently conducting 100% testing of someone else’s compiler is also a little elevating task. Fortunately, in the last 5 years, many leading manufacturers of programmable chips (CPU, FPGA / CPLD) have entered the market with versions of compilers that are already certified according to the requirements of IEC 61508. Such tools can be used to develop products that meet the requirements of IEC 61508. There are two problems here: the high cost of many such tools (usually thousands of dollars) and the fact that they are far from compatible with all the chips supported by generic versions of compilers.



An area close to the toolkit is the selection and application of coding rules that require the use of a limited secure set of programming language designs.



What should I look for when using tools? There are several provisions defined in the requirements of IEC 61508:

- for toolkits of classes T2 and T3 requirements specifications or user documentation should be available that uniquely describe how the operation takes place;

- for tools of classes T2 and T3, their compliance with the requirements specification or user documentation, for example, in the form of a certificate, must be documented;

- the versions of the tools used should be monitored, since not all versions can meet the specified conditions; all project participants must use the same version; For transitions between versions, the appropriate procedure should be applied;

- if the tools are used as a single technological complex (for example, code and tests are generated on the basis of the specification), their compatibility with each other should be tested.



To ensure compliance with these requirements, it is advisable to develop a special Report on the selection and evaluation of tools (Tools Selection and Evaluation Report, TSER). It should include:

- A description of the stack of tools used (both software and hardware, both commercially available and self-developed) used for product development, its testing, and supporting processes (configuration management, a set of text documents, project management, etc.) ); for each of the tools you should specify: type (to support which process is used), name, version number, supplier name, class (T1, T2 or T3), generated outputs in terms of Configuration Items;

- results of evaluation (analysis) of tools according to a set of predetermined criteria, such as, for example, the functions performed and their applicability in this project, experience of use, available documentation, information about the supplier (market reputation, quality management system, approach to configuration management and etc.), the impact on the safety of the product, the errors found and eliminated, possible risks of use from the point of view of failures and the strategy for managing these risks.



If the project is carried out using a waste technology stack, then a typical TSER can be used or refined.

Verification and Validation

The implementation of this process depends on the structure of the selected life cycle, so it makes sense to consider the details in the planned publication on the functional safety life cycle (Functional Safety Life Cycle).



It should be noted that verification and validation include not only testing, but also reviews of project documents, analysis of types and consequences of failures (Failure Mode and Effect Analysis), static code analysis, etc.



In order to manage functional safety, it makes sense to develop a high-level Verification and Validation (V & V) Plan, which includes the following provisions (see Figure 8):

- A description of the organization of the V & V process and the allocation of resources for implementation;

- V & V stages in connection with the development stages;

- Methods and tools for performing V & V;

- requirements for documenting V & V results;

- processing requirements for detected anomalies.







Figure 8. Structure of the Verification and Validation Plan



Plans, specifications and reports on individual reviews, analyzes and tests, as a rule, are self-contained documents.

Documentation Management

Documentation requirements are contained in clause 5 of IEC 61508-1. The basic requirements are as follows:

- documents must contain sufficient information, both for subsequent stages of development and for verification of the results of the current stage;

- the documents must contain sufficient information, both to ensure and to evaluate functional safety;

- Documents should be available to project officials for the development and certification of products (software and systems) related to security;

- documents must have a version number and date of last change; Changes to documents must be made according to the Change Control procedure mentioned above.



For detailed documentation management planning we develop an appropriate plan (Documentation Plan). Note that this plan does not apply to the organization as a whole, but only to the participants of a certified project for developing a product important to security (software or system). It should contain (see Figure 9):

- requirements for identification, development, execution, coordination and approval of documents;

- Review procedure and criteria for evaluating documents (for example, in the form of checklists); in particular, the criteria for evaluating documents in accordance with IEC 61508 are: accuracy, brevity, clarity, suitability or suitability for purpose, accessibility for use and maintainability;

- list of project documents and development responsibility;

- procedure for organizing access and access rights of project participants to documents;

- the procedure for making changes to documents, accounting policy and version changes;

- requirements for the use of electronic document management system (EDCS - Electronic Document Control System) and the structure of the project repository.







Figure 9. Documentation Plan structure (Documentation Plan)



Based on my own experience, I can say that it is convenient to keep a list of documents in a separate appendix to the documentation plan, since this is quite a dynamic part of planning.



Documents developed in the project related to ensuring functional safety. include the following types (see figure 10):

- the functional safety planning documents considered in this article;

- specification of requirements (Safety Requirements Specification, SRS) and system architecture (System Architecture Design, SAD);

- the project of hardware, also called the design documentation (Hardware Design);

- software project (Software Design);

- Verification and validation documents;

- documents related to the so-called qualification testing of equipment (Equipment Qualification Testing) for resistance to extreme impacts; The levels of such impacts as climatic (temperature and humidity), mechanical (impacts, resonance search, transport shaking, seismic), and electro-magnetic are usually specified;

- the above documents related to the tools (user manuals, specifications of requirements, certificates confirming compliance with the requirements, information about suppliers);

- The Change Control documents reviewed above;

- user documentation for the supplied product, including the safety user's manual (Product Safety Manual);

- guidelines, procedures and instructions used in the project for the organization of work; such documents may be used by company practices or may be developed specifically for a project related to functional safety.







Figure 10. Classification of documentation for projects related to functional safety

Functional Safety Assessment

Now let's see how functional safety is assessed.

For this purpose, periodic functional safety audits (Functional Safety Audit) are conducted in the course of operating activities.

In addition, during certification, processes and product are evaluated by a certifying organization, which results in a certificate of conformity. The most well-known certifiers of functional safety is the TÜV group of companies.

Audits should be conducted according to pre-designed plans (Functional Safety Audit Plan). The plans should be defined:

- the frequency of audits (for example, at the completion of each of the development stages);

- area of ​​evaluation in terms of products and processes;

- involved organizations and other required resources;

- level of independence of the adherents; audits can be internal, then the auditors are project participants not involved in the processes that are audited; in addition, the certifying organization may also participate in periodic audits; in general, the issue of independence in evaluating safety has its own traditions in various industries;

- competence of the persons performing the audit;

- Expected results;

- organization of corrective actions.

The initial data for compiling an audit checklist are the requirements of the FSMP and other subordinate plans discussed in this article.

According to the results of the audits, the appropriate Functional Safety Audit Reports should be issued.

findings

The article analyzes the provisions of IEC 61508 relating to functional safety management (Functional Safety Management) and functional safety assessment (Functional Safety Assessment).

The implemented processes are consistent with the basic principles of project management, as well as software and system engineering.

Interpretation of requirements may differ slightly for different areas of the industry, since their own standards have been developed for them, which, nevertheless, are largely harmonized with IEC 61508.

The material offered to the reader is confirmed by experience (6 years in successful certification projects) when working with certification companies exida and TÜV .



PS To explain the main aspects of functional safety, the following cycle of articles is developed:

- Introduction to the subject of functional safety ;

- Standard IEC 61508: terminology ;

- IEC 61508 Standard: requirements structure ;

- The relationship between information and functional safety of the process control system ;

- Management processes and functional safety assessment ;

- The life cycle of information and functional security ;

- The theory of reliability and functional safety: basic terms and indicators ;

- Methods to ensure functional safety .



Here you can watch video lectures on the topic of publication.