WO2020130173A1

WO2020130173A1 - Safety activity management method for safety critical system, and safety activity management device therefor

Info

Publication number: WO2020130173A1
Application number: PCT/KR2018/016130
Authority: WO
Inventors: 한혁수; 김은비
Original assignee: 상명대학교산학협력단
Priority date: 2018-12-18
Filing date: 2018-12-18
Publication date: 2020-06-25

Abstract

Disclosed is a safety activity management device for a safety critical system. The safety activity management device may comprise: a first control unit for generating a commit message for managing calculation data of a safety activity and transmitting the commit message to a second control unit; and the second control unit for managing information about a safety activity issue on the basis of information included in fields of the transmitted commit message. Here, the commit message may include a field for status information of the safety activity issue, a field for an identification (ID) of the safety activity issue, and a field for information of a sub-safety activity issue of the safety activity issue.

Description

Safety activity management method of safety essential system and safety activity management device

The present invention relates to a safety activity management method of a safety-critical system and a safety activity management device, and more particularly, to a safety activity management method and a safety activity management device for managing safety issues when developing a system in an industrial field. .

Safety critical systems are becoming larger. In particular, as the weight of electrical, electronic, and software starts to increase, the risk of accidents due to software defects and interaction errors between system components as well as mechanical failures increases.

In order to prevent fatal accidents, in safety-critical industries such as automotive, medical, and aviation, a functional safety standard has been established based on the IEC 61508, a meta model of functional safety, in accordance with the characteristics of each industry. These standards define stringent safety activities that must be followed throughout the development life cycle to ensure system safety. Safety activities are centered on identifying potential hazards that cause accidents and deriving safety requirements to address them.

Safety-critical systems are activities that identify hazards and assess risks according to the safety lifecycle defined in IEC 61508, activities that specify safety requirements to eliminate or mitigate hazards, and safety requirements. It should be developed on the basis of design, development activities to verify the implementation, activities to verify the implemented safety requirements, and safety activities on system operation and maintenance.

Hazards are potential hazards that can cause accidents in the system, and all cases that can deviate from the normal operation of the system are targeted. Because identifying the hazards as much as possible is essential to ensuring safety, hazard analysis activities should be conducted throughout the entire development life cycle.

The safety requirements specified on the basis of hazard analysis should be reflected in the design and implementation and the accuracy should be verified through testing. For this reason, it is necessary to define a process for managing safety activities and to systematically track safety activities based on the process.

The present invention can provide a method and apparatus for systematically tracking and managing outputs from a safety activity process in parallel with a system development activity process in an industrial field.

The present invention can provide a method and apparatus capable of grasping the progress of system development activities in an industrial field in real time.

The safety activity management device of a safety critical system according to various embodiments of the present invention is a first control unit that generates a commit message for managing the calculated data of the safety activity and delivers it to the second control unit And a second control unit managing information on a safety activity issue based on information included in fields of the transmitted commit message. Here, the commit message may include a field for status information of the safety activity issue, a field for identification (ID) of the safety activity issue, and a field for information on a safety activity issue below the safety activity issue.

The safety activity management method of a safety-critical system according to various embodiments of the present invention includes a process of generating a commit message for managing the calculated data of the safety activity and transmitting it to a second control unit and fields of the transmitted commit message It may include the process of managing information on safety activity issues based on the information. Here, the commit message may include a field for status information of the safety activity issue, a field for ID of the safety activity issue, and a field for information on a safety activity issue below the safety activity issue.

According to various embodiments of the present invention, it is possible to systematically track and manage the output from the safety activity process in parallel with the system development activity process in the industrial field.

According to various embodiments of the present invention, it is possible to grasp in real time the progress of a system development activity in an industrial field.

1 shows a system development activity process and a safety activity process according to an embodiment of the present invention.

Figure 2 shows the output of the safety activity process according to an embodiment of the present invention.

3 is a block diagram of a safety activity management device of a safety essential system according to an embodiment of the present invention.

4 illustrates an issue tracking system and a version control system according to an embodiment of the present invention.

5 shows an issue tracking system and a version control system according to another embodiment of the present invention.

6 illustrates an issue tracking system according to an embodiment of the present invention.

7 is a detailed block diagram of a safety activity management device according to an embodiment of the present invention.

8 is a flow chart of a method for managing safety activities of a safety-critical system according to an embodiment of the present invention.

Hereinafter, the operation principle of the preferred embodiment of the present invention will be described in detail with reference to the accompanying drawings. In addition, in describing embodiments of the present invention, when it is determined that detailed descriptions of related known functions or configurations may obscure the subject matter of the present disclosure, detailed descriptions thereof will be omitted. In addition, terms used in the following are terms defined in consideration of functions in the present invention, which may vary according to a user's or operator's intention or practice. Therefore, the definitions of terms used should be interpreted based on the contents throughout the specification and corresponding functions.

Systems in safety critical industries such as medical, automotive, and aviation (safety field systems) can cause personal injury in the event of an accident. Therefore, when developing a system, activities to ensure safety must be performed.

In general, modeling techniques recognized as standards have been used to systematically develop systems. In software development, a unified modeling language (UML) was adopted as a company standard, and in system development, an extended model of UML, SysML (system modeling language), has been recognized as a suitable modeling language.

An example of a system development in the industrial field is the development of a radiation treatment planning system (RPTS) in the medical field. The radiation treatment planning system may be a system that analyzes a treatment area to perform radiation treatment, calculates a therapeutic radiation dose, and plans radiation to be injected into a target area. Here, the safety activity may be defined as an activity that supplements the safety of the radiation treatment planning system by predicting an accident risk that may be caused in the radiation treatment planning system.

Referring to Figure 1, the system development activity process (1) and safety activity process (2) is largely a concept (concept) stage (11), a design (design) stage (12), a development (development) stage (13) and operation And operating and maintenance steps 14.

Here, the system development activity process 1 includes a requirements analysis step 21, a design step 22, an implementation step 23, a testing step 24, and a maintenance step ( 25).

In addition, the safety activity process 2 includes a hazard and risk analysis step 31, a safety require analysis step 32, a safety design step 33, and an implementation step. (34), a testing step (35) and a maintenance step (36).

At each stage of the safety activity process, a work product (or output data, result data, output) occurs. Here, the output may be various, such as source code and documents.

1 and 2, the safety requirement 41 is calculated as the risk request analysis step 32 is performed, and the safety mechanism 42 is calculated and implemented as the safety design step 33 is performed. As step 34 is performed, the safety function 43 is calculated, as the testing step 35 is performed, a safety test case 44 is calculated, and as the maintenance step 36 is performed, field requirements ( 45) can be calculated. As an example, the safety requirement 41 may be calculated based on safety analysis based on multi-view modeling (SAMM).

In addition, the defects derived based on the requirements 48 derived based on the requirements analysis step 21 of FIG. 1, the safety function 43, the safety test case 44 and the field requirements 45 Accordingly, management of the hazard 47 may be performed.

The safety activity management device 300 may include a first control unit 310 and a second control unit 320. Here, the first control unit 310 and the second control unit 320 may be defined as a first processor and a second processor, respectively. In this case, the first processor and the second processor may be physically divided, or may correspond to at least one module included in one processor. In addition, the safety activity management device 300 may be various electronic devices such as a personal computer (PC), a smart phone, a tablet PC, and a server.

The first control unit 310 may generate a commit message. Here, the commit message is for managing the output data of the safety activity. By reflecting the information contained in the commit message to the safety activity process (or system), the current status of the safety activity can be updated and issues of the safety activity can be managed. For example, the safety activity issue may be at least one of a safety requirement, a safety mechanism, a safety function, a safety test, and a field requirement. . Here, from the safety requirements to the field requirements, it can be defined as a sub safety activity issue.

For example, the commit message includes a field for status information of a safety activity issue, a field for identification (ID) of the safety activity issue, and a field for information on a safety activity issue below the safety activity issue.

Here, the status information of the safety activity issue may be one of implementation progress and implementation closed.

In addition, the field for the ID of the safety activity issue may include at least one of ID information of a safety requirement, ID information of a safety mechanism, ID information of a safety function, ID information of a safety test, and ID information of a field requirement. .

For example, when the safety activity issue is a safety mechanism, a field for information on a lower safety activity issue may be a field for a safety function. Here, the field for the safety function may include information about the safety function and data including information about the safety function.

As another example, the commit message includes a field for status information of a safety activity issue, a field for ID (identification) of the safety activity issue, and a field for information on a safety activity issue below the safety activity issue, as well as a work history. It may further include a field for.

The first control unit 310 may transmit the generated commit message to the second control unit.

The second control unit 320 may manage information on safety activity issues. Specifically, the second control unit 320 may manage information on a safety activity issue based on information included in fields of the transmitted commit message. Detailed embodiments of managing information on safety activity issues will be described in detail below with reference to FIGS. 4 and 5.

The issue tracking system 400 is a system for managing safety issues that occur during system development. The version control system 500 is a system for managing outputs in a system development process. As an example, the output may be stored in a source code repository.

The issue tracking system 400 and the version control system 500 may be constructed by being interconnected with a tool chain. Here, the tool chain continuously integrates the integrated management environment (IDE), an integrated development environment, a build system for performing a build in the same environment, and outputs of the system development process, and analyzes statically at every build. At least one of a continuous integration system for performing dynamic testing may be further included.

Referring to FIG. 4, the first control unit 310 may generate a commit message 501. For example, the commit message 501 is a field for status information of a safety activity issue (eg, implementation progress), a field for ID of a safety activity issue (eg, #1067), and a field for work history (day For example, a checking model may be implemented and a field for information on a safety activity issue below the safety activity issue (eg, +SF=RTPS_Interface.dicomChecking()) (eg, all fields may be included). The commit message can be generated with “implementation progress: #1067 checking model implementation +SF=RTPS_Interface.dicomChecking()”). Here, each field of the commit message 501 may be input or set according to predetermined field information.

The first control unit 310 may transfer (or commit) the generated commit message 501 to the second control unit 320.

The second control unit 320 may manage information on safety activity issue #1067 (safety activity issue ID) based on the commit message 501.

For example, the second control unit 320 reflects information (eg, implementation progress) included in the field for the status information of the safety activity issue of the commit message 501 in the status field 401, and the commit message ( Information included in the field for the ID of the safety activity issue (501, for example, #1067) is linked to the safety activity issue ID field 402, and information included in the field for the work history (eg, checking ( (checking) model implementation) is reflected in the history field 403, and information included in the field for information on the safety activity issue below the safety activity issue of the commit message 501 (eg, +SF=RTPS_Interface.dicomChecking( )) may be reflected in the safety function field 404.

According to the embodiment of FIG. 4, the safety activity process is applied to the system development process by reflecting the output according to the safety activity process stored and managed in the version control system 500 in the issue tracking system 400 through the commit message 501. Can be integrated and managed. Through this, safety requirements can be efficiently reflected at each stage of the system development process.

Referring to FIG. 5, the first control unit 310 may generate a commit message 701. For example, the commit message 701 is a field for status information of a safety activity issue (eg, Design), a field for ID of a safety activity issue (eg, #1041), and a field for a job history (eg , Checking (identification of the checking mechanism) and fields for information on safety activity issues below the safety activity issue (eg, +SF=Interface Data Checking) (eg, a commit message including all fields) , “Design: #1041 checking model implementation +SF=Interface Data Checking”). Here, each field of the commit message 701 may be input or set according to predetermined field information.

The first control unit 310 may transfer (or commit) the generated commit message 701 to the second control unit 320.

The second control unit 320 may manage information on safety activity issue #1041 (safety activity issue ID) based on the commit message 701.

For example, the second control unit 320 reflects information (eg, Design) included in the field for the status information of the safety activity issue of the commit message 701 in the status field 601, and the commit message 701 ) Information contained in the field for the ID of the safety activity issue (eg, #1041) is linked to the safety activity issue ID field 602, and information included in the field for the job history (eg, checking (checking) ) Model implementation) may be reflected in the history field 603.

According to the embodiment of FIG. 5, the safety activity process is applied to the system development process by reflecting the output according to the safety activity process stored and managed in the version control system 700 in the issue tracking system 400 through the commit message 701. Can be integrated and managed. Through this, safety requirements can be efficiently reflected at each stage of the system development process.

Referring to the issue tracking system 800 of FIG. 6, the second control unit 320 may manage safety requirements. Specifically, the second control unit 320 identifies safety requirements (811), safety request specifications (812), safety request termination (813), design (814), implementation (815), testing (816) and termination (817) ) Safety requirements can be managed in order.

Here, the safety requirement identification 811 is a state in which an initial list of safety requirements is identified. The safety requirements specification 812 is in the state of specification of safety requirements. The safety request end 813 is a state in which the specification of the safety requirement is completed and the baseline is established. Design 814 is in the design phase. Implementation 815 is in an implementation phase. The testing 816 is in the state of testing. End 817 is a state in which the implementation of the safety requirements has been confirmed.

In the process of design 814, the second control unit 320 performs the process of mechanism identification 821, design progress 822, and design termination 823. Here, the mechanism identification 821 is a state in which an initial list of safety mechanisms has been identified and registered. The design progress 822 is a state in which analysis and specification of safety mechanisms are in progress. The design end 823 is a state in which the analysis and specification of the safety mechanism have been completed.

In the implementation 815, the second control unit 320 may include a function identification 824, an implementation progress 825 and an implementation termination 826 and termination 827. The function identification 824 is a state in which an initial list of safety functions has been identified and registered. The implementation progress 825 is a state in which the implementation of the safety function is in progress by the developer (or development tool). The implementation end 826 is a state in which the implementation of the safety function has been completed by the developer (or development tool). End 827 is a state in which the implementation of the safety mechanism has been confirmed.

The second control unit 320 may manage defects for the safety function 43, the safety test case 44, and the field requirement 45 of FIG. 2 described above. The second control unit 320 may manage the defect as a hazard when the defect is a new (831). For example, the second control unit 320 may end the defect management process 832 when it is determined that the defect is not new or is not a defect.

The second control unit 320 may manage hazards. The second control unit 320 may receive and identify a hazard list or a defect list (841) and analyze 842. If determined to be a hazard, the second control unit 320 may initiate an action (845) to terminate the hazard management (846). Alternatively, the second control unit 320 may determine that it is not a hazard (844).

Referring to FIG. 7, the safety activity management device 900 includes a communication unit 910, a storage unit 920, and a processor 930.

The communication unit 910 performs communication.

The communication unit 510 performs communication with an external electronic device through various communication methods such as wired or BT (BlueTooth), WI-FI (Wireless Fidelity), Zigbee, IR (Infrared), and NFC (Near Field Communication). Can.

The storage unit 920 may store an O/S (Operating System) software module for driving the safety activity management apparatus 900, data for configuring various UI screens provided in the display area, and the like. For example, the storage unit 920 may include software for driving an issue tracking system or a version control system, UX/UI data, and the like. Also, the storage unit 920 may pre-store information about fields included in the commit message.

The processor 930 controls overall operations of the safety activity management apparatus 900 using various programs stored in the storage unit 920.

Specifically, the processor 930 includes a RAM 931, a ROM 932, a graphics processor 933, a main CPU 934, first to n interfaces 935-1 to 935-n, and a bus 937. Includes.

The RAM 931, the ROM 932, the graphic processing unit 933, the main CPU 934, and the first to n interfaces 935-1 to 935-n may be connected to each other through the bus 937.

ROM 932 stores a set of instructions for booting the system. When the turn-on command is input and power is supplied, the main CPU 934 copies the O/S stored in the storage unit 920 to the RAM 932 according to the command stored in the ROM 932, and executes the O/S. Boot the system. When the booting is completed, the main CPU 934 copies various application programs stored in the storage unit 920 to the RAM 931 and executes the application programs copied to the RAM 931 to perform various operations.

The graphic processing unit 933 generates a screen including various objects, such as icons, images, and text, by using a calculation unit and a rendering unit.

The main CPU 934 accesses the storage unit 920 to boot using the O/S stored in the storage unit 920. Then, various operations are performed using various programs, contents, data, etc. stored in the storage unit 920.

The first to n interfaces 935-1 to 935-n are connected to various components described above. For example, one of the interfaces may be a network interface connected to an external device through a network.

The processor 930 may generate a commit message for managing the safety activity calculation data. Also, the processor 930 may manage information on a safety activity issue based on information included in fields of the generated commit message. Here, the operations of the processor 930 may be performed by at least one of the lower first to nth processors.

The safety activity management method is a process of generating a commit message for managing the calculated data of the safety activity and delivering it to the second control unit (1010) and information on the safety activity issue based on information included in the fields of the transmitted commit message. It may include the process of managing (1020). Here, the commit message may include a field for status information of a safety activity issue, a field for identification (ID) of a safety activity issue, and a field for information on a safety activity issue below the safety activity issue.

Here, the safety activity issue may be at least one of a safety requirement, a safety mechanism, a safety function, a safety test, and a field requirement.

In the above-described example, the status information of the safety activity issue may be one of implementation progress and implementation closed.

In addition, the field for the ID of the safety activity issue may include at least one of ID information of a safety requirement, ID information of a safety mechanism, ID information of a safety function, ID information of a safety test, and ID information of a field requirement. have.

For example, when the safety activity issue is a safety mechanism, a field for information on a lower safety activity issue may be a field for a safety function.

In the above example, the field for the safety function may include information about the safety function and data including information about the safety function.

As another example, the commit message may further include a field for a job history.

On the other hand, the safety activity management method according to various embodiments of the present disclosure described above is implemented as a computer executable program code and stored in various non-transitory computer readable media to be executed by the processor. It may be provided to a server or devices.

For example, the process of generating a commit message for managing the calculated data of safety activity and transferring it to the second control unit and managing the information on the safety activity issue based on information included in the fields of the transmitted commit message are performed. A non-transitory computer readable medium in which a program to be stored is stored may be provided.

The non-transitory readable medium means a medium that stores data semi-permanently and that can be read by a device, rather than a medium that stores data for a short time, such as registers, caches, and memory. Specifically, the various applications or programs described above may be stored and provided in a non-transitory readable medium such as a CD, DVD, hard disk, Blu-ray disk, USB, memory card, ROM, and the like.

In addition, although the preferred embodiments of the present disclosure have been illustrated and described above, the present disclosure is not limited to the specific embodiments described above, and the technical field to which the present invention pertains without departing from the gist of the present disclosure claimed in the claims. In addition, various modifications can be carried out by a person having ordinary knowledge, and these modifications should not be individually understood from the technical idea or prospect of the present disclosure.

Claims

In the safety critical system (safety critical system) safety activity management device,

A first control unit that generates a commit message for managing the calculated data of the safety activity and delivers it to a second control unit; And

It includes; a second control unit for managing information on the safety activity issue based on the information included in the fields of the transmitted commit message;

The commit message,

And a field for status information of the safety activity issue, a field for ID (identification) of the safety activity issue, and a field for information on a safety activity issue below the safety activity issue.
According to claim 1,

The safety activity issues are:

A safety activity management device, which is at least one of a safety requirement, a safety mechanism, a safety function, a safety test, and a field requirement.
The method according to claim 1 or 2,

The status information of the safety activity issue,

Safety activity management device, which is one of implementation progress and implementation closed.
The method according to claim 1 or 2,

The field for the ID of the safety activity issue,

A safety activity management device comprising at least one of ID information of a safety requirement, ID information of a safety mechanism, ID information of a safety function, ID information of a safety test, and ID information of a field requirement.
According to claim 1,

When the safety activity issue is a safety mechanism, a field for information on the lower safety activity issue is a field for a safety function.
The method of claim 5,

The field for the safety function,

A safety activity management device including information on the safety function and data including information on the safety function.
The method according to claim 1 or 2,

The commit message,

A safety activity management device further comprising a field for a work history.
In the safety critical system (safety critical system) safety activity management method,

Generating a commit message for managing the calculated data of the safety activity and delivering it to a second control unit; And

Includes a process of managing information on safety activity issues based on information included in the fields of the transmitted commit message.

The commit message,

And a field for status information of the safety activity issue, a field for identification (ID) of the safety activity issue, and a field for information on a safety activity issue below the safety activity issue.
The method of claim 8,

The safety activity issues are:

A method of managing safety activities, at least one of a safety requirement, a safety mechanism, a safety function, a safety test, and a field requirement.
The method of claim 8 or 9,

The status information of the safety activity issue,

Safety activity management method, which is one of implementation progress and implementation closed.
The method of claim 8 or 9,

The field for the ID of the safety activity issue,

A safety activity management method comprising at least one of ID information of a safety requirement, ID information of a safety mechanism, ID information of a safety function, ID information of a safety test, and ID information of a field requirement.
The method of claim 8,

When the safety activity issue is a safety mechanism, a field for information on the lower safety activity issue is a field for a safety function.
The method of claim 12,

The field for the safety function,

A safety activity management method comprising information on the safety function and information on data including information on the safety function.
The method of claim 8 or 9,

The commit message,

A safety activity management method further comprising a field for a work history.