Functional Safety, Part 4 of 7. Management and Evaluation Processes
A whole hub is dedicated to security on a hub , and, perhaps, no one really thinks what exactly is invested in the concept of "security", and so everything is clear: information security (security). However, there is another side to safety, safety, associated with risks to human health and life, as well as the environment. Since information technologies themselves are not dangerous, they usually talk about the functional component, that is, about the security associated with the proper functioning of a computer system. If information security became critical with the advent of the Internet, then functional security was considered before the advent of digital control, because accidents always happened.
This article continues a series of publications on functional safety.
In this article, rather abstract requirements for functional safety management are interpreted for implementation in work processes. This information has been verified and polished in practice by several certification projects.
Process Engineering - Is it Boring or Not? It is processes that allow you to scale your IT business. I personally had to observe how the introduction of processes into development led to serious professional growth, both of performers and of the whole company. And vice versa, “plugs” and the so-called “inexpediency” of introducing well-structured processes testified to immaturity and other serious problems.
In a previous article , the structure of functional safety requirements was considered (see Figure 1). Now we will focus on two aspects: Functional Safety Management and Functional Safety Assessment.
Figure 1. Structure of the requirements of IEC 61508
Functional Safety Management Plan
Functional safety management processes are in many respects consonant with 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 main scope of requirements is presented in IEC 61508-1; IEC 61508-2 contains only a reference to part 1, IEC 61508-3 contains an addition to software configuration management.
Now let’s 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 — the Functional Safety Management Plan (FSMP). Such a plan will include several areas:
- Human Resource Management;
- configuration management;
- selection and evaluation of development tools (Tools Selection and Evaluation);
- Verification and Validation;
- 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 fairly extensive, dynamic and partially autonomous process from others, it is recommended that each of them develop and maintain its own separate documents (plans and reports). In FSMP, it makes sense to leave the fundamental points, without details.
In addition, FSMP should contain the following sections (they are either quite simple or are beyond the scope of this publication and will be considered in the 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, in this part we can summarize the main provisions of FSMP;
- Suppliers Management includes interaction with suppliers of products and services that affect the provision of functional safety; this requirement came from a quality management system (ISO 9001); in terms of Project Management, procurement management is an analogue; IEC 61508 requires suppliers to have a quality management system in place; if suppliers have an ISO 9001 certificate, then there are no problems (and vice versa);
- information security (Security); IEC 61508 only briefly talks about this important property, which, of course, does not mean that attention is not paid to this aspect; these properties are described in other standards, and certification according to their requirements is a separate process; as for 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 must be described in stages in the FSMP; we will consider this component in a separate publication, as well as the adjoining process of tracing requirements (Requirement Tracing).
Thus, the considered FSMP structure is presented below in the form of Mind Maps.
Figure 2. Structure of the Functional Safety Management Plan (FSMP)
As already mentioned, many provisions in the management of functional safety overlap or are directly borrowed from project management. In addition, application of project management is recommended in IEC 61508, as one of the methods of protection against systematic failures. Therefore, such tools as the charter of the project, the project plan based on WBS, Action and Bug Trackers, etc. warmly welcomed and recommended for use. I will focus on what should be done in accordance with the requirements of the standard.
Human Resource Management
In principle, if the company already uses the Project Management (PMBOOK) methodology or something similar (for example, CMMI), then, as a rule, nothing special should be done in this direction. IEC 61508 requires pragmatic actions:
- designate responsible persons to carry out all necessary actions; since it also talks about the need to coordinate activities related to ensuring and evaluating functional safety, it is advisable to appoint the so-called Functional Safety Coordinator (or you can also assign such functions to the project manager);
- determine communication procedures between project officials, including third-party participants;
- develop all necessary procedures that would cover all areas listed in FSMP;
- organize the necessary staff training, guaranteeing 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 Organizational Chart and the Competency Matrix.
For detailed personnel management planning, we develop an appropriate plan (Human Resource Management Plan). Note that this plan does not apply to the organization as a whole, but only to participants in a certified project to develop a product (software or system) that is important for security. It should contain (see Figure 3):
- the organizational chart of the project with a description of the project roles;
- a list of project participants indicating the project roles and responsibility for planning and performing work at various stages of the life cycle;
- a matrix of competencies and conclusions about the adequacy or lack of competencies of the nominated performers (i.e. what knowledge and skills are required for a specific project role and how much does a particular employee correspond to them); here the question may arise: “how can people with insufficient competencies be appointed?”; in the real world, however, a shortage of resources, primarily human resources, is always observed; the positive news is that in the case of an uncritical lack of competencies of many performers, you can teach the missing skills and knowledge;
- staff training activities aimed at achieving and maintaining the above competencies critical for the implementation of the project; training plans and reports should be documented;
- communication plan of project participants;
- a sheet with the signatures of the staff, indicating familiarization with this plan.
Figure 3. The structure of the Human Resource Management Plan
This direction is also quite well-known and methodologically developed, since it has something in common with PMBOOK and CMMI. In terms of functional safety, the configuration management also includes Change Control and the implementation of software and hardware modifications, including decommissioning. Analysis of dangerous events falls into the same area, since various incidents are an input for making changes. Also, many useful points can be gleaned from the IEEE 828 Standard for Software Configuration Management Plan and, of course, from the blogs of the authors of the Habr, for example, "Notes by a retired siemshchik" from @Aguary .
When defining configuration items in the context of functional security, it is important to understand that they include not only familiar sources and builds of program code, but also much more: development and testing tools (about them a little later), a full set of design, user and any other relevant documentation (this is also slightly lower), including the design documentation, according to which all mechanical, electrical and electronic components are produced (see Figure 4).
Figure 4. Typical Configuration Items
This structure can serve as the basis for a project repository. Documents and tools will be described in more detail below.
Configuration management directly depends on the tools used, however, there are some general points that need to be included in the “Configuration Management Plan” (Configuration Management), 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 group should be organized with the involvement of all those individuals whose opinion is important to consider when making changes;
- An approach to planning and maintaining the configuration management process;
- resources of the configuration management process, primarily, the tools used (SVN, Git, etc.);
- the procedure for identifying all configuration components (Configuration Items) and the formation of basic versions (baselines);
- the procedure for the use of tools to control versions of software and hardware components of the product and to account for their status;
- procedure for accessing configuration components and backup storage;
- procedure and frequency of configuration audits;
- the procedure for analysis and elimination of detected defects, including those discovered during operation (this is one of the possible inputs for the next item - Change Control);
- Change Control Procedure, including Impact Analysis and validation of changes.
Figure 5. The structure of the Configuration Management Plan
The procedure for controlling changes is critical to the implementation and certification of processes. For formalization, phased processing of Change Requests is usually used. The stages of making changes are presented below in the diagram (see Figure 6) and include:
Submit - receipt of a request for changes, the reason may be any correction or revision;
Approve - consideration and formal approval of the request; Of course, the request may be rejected, then the subsequent steps are not performed;
Impact Analysis - analysis of the impact of the request on the functionality, security, volume and cost of work, etc .; it defines not only the scope of development, but also changes in documentation, testing and other checks related to verification and validation;
Implement - direct implementation of changes;
Verify - performing (possibly phased) various kinds of verification checks regarding the changes made;
Close - formal closure of the request for changes.
Figure 6. Change Control process based on processing change requests
Selection and evaluation of development tools (Tools Selection and Evaluation)
Instrumentation (IS) selection and evaluation activities are closely related to functional safety management, although the requirements are outlined 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), tools are classified as follows:
- tools of class T1 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;
- T2 class tools support testing and other types of verification (for example, static code analysis or analysis of test coverage completeness); however, there is no direct effect on the executable code, however, a problem in the testing tools can lead to the fact that errors in the software may not be detected; this class should include not only software, but also hardware-software simulators of input / output signals; it should be noted that the design tools for mechanical, electrical and electronic components (for example, printed circuit boards) can also be classified as T2;
- T3 class 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 typical tools for functional safety related projects
Justification of the possibility of using compilers for functional security purposes is the biggest problem, since the requirements for them are such that full testing of all functions affecting the generation of executable code should be carried out. It is unlikely that it will be possible to obtain such information privately from the developer, and to independently conduct 100% testing of someone else’s compiler is also a little lifting task. Fortunately, in recent years 5 many leading manufacturers of programmable chips (CPU, FPGA / CPLD) have entered the market with compiler versions already certified according to IEC 61508. Such tools can be used to develop products that meet the requirements of IEC 61508. There are two problems: the high cost of many such tools (usually thousands of dollars) and
A field close to tools is the selection and application of coding rules that require the use of a limited, secure set of programming language constructs.
What should I look for when using tools? There are several provisions specified in the requirements of IEC 61508:
- requirements specifications or user documentation should be available for tools of classes T2 and T3 that clearly describe how the operation occurs;
- for tools of classes T2 and T3, their compliance with the requirements specification or user documentation should be documented, for example, in the form of a certificate;
- The versions of the tools used should be monitored, since not all versions of the specified conditions can be met; 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 based on the specification), then 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 must include:
- a description of the stack of tools used (both software and hardware, both commercially available and in-house) used for product development, its testing, as well as supporting processes (configuration management, set of text documents, project management, etc. ); for each of the tools should indicate: type (to support which process is used), name, version number, vendor name, class (T1, T2 or T3), generated outputs in terms of configuration components (Configuration Items);
- the results of the assessment (analysis) of tools according to a set of specified criteria, such as, for example: the functions performed and their applicability in a given project, experience of use, available documentation, information about the supplier (market reputation, quality management system, configuration management approach and etc.), the impact on product safety, detected and resolved errors, possible risks of use in terms of failure manifestations and a strategy for managing these risks.
If the project is carried out using a proven technology stack, then a typical TSER can be used or finalized.
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 topic of the Functional Safety Life Cycle.
It should be noted that verification and validation include not only testing, but also reviews of project documents, analysis of the 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 top-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;
- requirements for processing detected anomalies.
Figure 8. Verification and Validation Plan structure The
plans, specifications, and reports for individual reviews, analyzes, and tests are typically stand-alone documents.
Documentation requirements are contained in clause 5 of IEC 61508-1. The basic requirements are as follows:
- the documents must contain sufficient information, both for the 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 the date of the last change; Changes to documents must be made according to the Change Control procedure mentioned above.
For detailed planning of document management, 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 in a certified project for the development of a product important to security (software or system). It should contain (see Figure 9):
- requirements for identification, development, execution, approval 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, conciseness, comprehensibility, suitability or suitability for use, availability for use and maintenance;
- A list of documents on the project and the distribution of responsibility for development;
- the procedure for organizing access and access rights of project participants to documents;
- procedure for making changes to documents, accounting policies 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. The structure of the Documentation Plan
Based on my own experience, I can say that it is convenient to maintain a list of documents in a separate appendix to the documentation plan, since this is a rather dynamic part of planning.
Documents developed in a project related to functional safety. include the following types (see Figure 10):
- functional safety planning documents reviewed in this article;
- Safety Requirements Specification (SRS) and System Architecture (SAD);
- hardware project, also called hardware design documentation;
- software project (Software Design);
- documents on verification and validation;
- Documents related to the so-called Equipment Qualification Testing for resistance to extreme impacts; usually set the levels of such effects as climatic (temperature-humidity), mechanical (shock, resonance search, transport shaking, seismic), electromagnetic;
- the documents considered above related to tools (user manuals, requirements specifications, certificates confirming compliance with requirements, information about suppliers);
- the above documents on change management (Change Control);
- user documentation for the supplied product, including the user manual for safety (Product Safety Manual);
- Guides, procedures and instructions used in the project to organize work; such documents can be used by the company’s practices or can be developed specifically for a functional safety project.
Figure 10. Classification of documentation for functional safety related projects
Functional Safety Assessment
Now let's see how functional safety is evaluated.
To do this, in the course of operations, periodic functional safety audits are carried out.
In addition, during the certification process, an assessment is made of the processes and product by the certification organization, according to the results of which a certificate of compliance is issued. The most famous functional safety certifiers are the TÜV Group of Companies.
Audits should be conducted in accordance with Functional Safety Audit Plan. The plans should determine:
- the frequency of audits (for example, upon completion of each of the development stages);
- area of assessment in terms of products and processes;
- organizations involved and other required resources;
- the level of independence of aditors; audits can be internal, then the auditors are project participants who are not involved in the processes that are being audited; in addition, the certification organization may also participate in periodic audits; in general, the issue of independence in assessing security has its own traditions in various industries;
- the competence of the persons performing the audit;
- Expected results;
- organization of actions to eliminate deficiencies.
The initial data for preparing the audit checklist are the requirements of FSMP and other subordinate plans discussed in this article.
Based on the results of the audits, the corresponding Functional Safety Audit Reports should be issued.
The article analyzes the provisions of IEC 61508 related to Functional Safety Management and Functional Safety Assessment.
The implemented processes comply with the main provisions of project management, as well as software and systems engineering.
The interpretation of the requirements may differ slightly for different areas of the industry, since they have developed their own standards, 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 exida certification companies and TÜV .
PS To explain the main aspects of functional safety, the following series of articles
is being developed: - Introduction to the topic of functional safety ;
- IEC 61508 standard: terminology ;
- IEC 61508 standard: requirements structure ;
- The relationship between information and functional safety of industrial control systems ;
- The processes of management and evaluation of functional safety ;
- The life cycle of information and functional security ;
- Theory of reliability and functional safety: basic terms and indicators ;
-Methods of ensuring functional safety .
Here you can watch video lectures on the topic of publication.