Safety-related software systems should be designed to ensure the reliability, safety, and quality of the system based on simplification, standardization, and specialization. These systems must be supported by software engineering processes such as development methodologies and verification methodologies that adhere to strict requirements and criteria to minimize the probability of failure. In this paper, a strict development and V&V methodology is defined according to the software life cycle, and the JY-methodology is proposed to satisfy traceability by separating the developer’s activities from the verifier’s activities to generate verifiable outputs at each software development life cycle as shown in Figure 4. The developer’s process defined in this paper are the ERD-Context Diagram-functional decomposition process and operational scenario in the requirement phase. In the design phase, task analysis and task allocation and module design activities are defined. In the implementation phase, it was recommended to utilize essential coding guidelines for safety. Verification and Validation activities defined the developer’s activities to include the left-hand side of the V-shape to include the test phase, installation and commissioning phase, and operation/maintenance phases. The developer’s testing was characterized as informal testing, while formal testing ac-cording to standards, plans, and procedures was categorized as a verifier activity. The detailed process of their development and verification activities is shown in Figure 4 and Figure 5. The development methodology is based on structured analysis and structured design, which have been proven in the software engineering field for a long time. The development methodology is as follows: Information modeling -> Context diagram -> Functional decomposition -> Task analysis & Allocation -> Module design -> Implementation -> Module test -> Integration/System test -> Installation/commission & operation. (Figure 4 and Figure 5) The verification method according to the development methodology is verified by Traceability Analysis and Ranked Check List method from Information modeling to Module design. At this time, FMEA related to safety is performed at the design phase. In the test phase, independent testing is performed according to the verification guidelines from the informal testing performed by the developer separately. The developer performs informal testing and the verifier performs formal testing. The main difference between them is that informal testing is performed without formal test criteria and formal test procedures. Formal testing means to perform test according to formal test criteria and test procedures. During formal testing, the verifier tests the module to satisfy statement coverage, condition/decision coverage, and Modified Condition/Decision Coverage (MC/DC). In the integration test phase, memory leak test and load balancing test are performed. System tests include interface tests, functional tests, and performance tests. The main difference between the tests performed by the developer and the verifier is that the verifier’s tests are performed independently of the developer, according to the verification criteria and procedures, and are formally tested with additional test cases created by the verifier. Detailed processes are shown in Figure 4 and Figure 5 respectively.

Select the candidate Entity and Attribute: NPP, sensor_detector, mechanic, registration etc o Define the Data Dictionary (DDE) - NPP = @plant_no + model_type + construction_date + life_span - sensor_detector = @sensor_id + location + timing_tag etc o Define the Relationship - 1 “exactly one” - N “one or more” - 0<=N “zero or more” - 0<=N<=1 “at most one”

The most important part of the development process is information modeling (data modeling). In information modeling, an E-R Diagram (Entity-Relationship Diagram) is created and data dictionary is created. The data dictionary is commonly used to maintain consistency throughout the all of the lifecycle. Some kinds of tools can be used to create databases based on E-R diagrams, and the creation of the database can be automated. The data modeling is the basis of any design. Here’s a simple example.

The following process creates an Event-Response List (ERL) table. For every event in the target system you want to develop, create Event[condition]/Response in the form of input, output, and storage (memory) in the form of Trigger/Action. Using the ERL create a Context Diagram so that you can grasp the means and goals you want to overall development status at a glance. Context Diagram defines the marginal environment such as input, output, etc. and creates an operation scenario. The Context Diagram is the beginning of the requirements phase, which includes functional analysis. Through functional analysis, control specification and process specification are defined, and later, a test plan is created for system testing. The hierarchical functional decomposition is done in a top-down format with three to five layers (not more than seven layers). Each function reuses design data from the previous information modeling (E-R Diagram). The design phase assigns the features defined in the previous requirements phase to tasks. This can be a 1:1 assignment or a M:1 assignment. Task allocation is done through task analysis such as transform rules and transaction rules. When designing, we define the top class, sub-class, and the lowest leaf-module, and design the leaf-module to be the smallest unit. Leaf-modules are represented by pseudo code or algorithms. In the implementation phase, a programming language is selected to generate the source code. It is recommended to use a programming language that is already proven in safety-related system. Examples include Ada, C, and Pascal etc. It is important to note that scripted languages should never be used in safety applications because of vulnerabilities. The left part of Figure 6 is the JY-development methodology, which is a reference of the Yourdon/Demacro [1] structured analysis and structured design methodology proposed in this paper. Here, the unit test, integration test, and system test are performed by the developer, but as an informal procedure, and all formal test/verification procedures are performed by the verification and validation team according to the test plan and test procedure.

The verification process corresponds to each development methodology process. The blue color part in Figure 7 is the verification methodology that corresponds to the development methodology. It should be performed in all software development life cycle activities. At the top level, it is reviewed with a ranked checklist and traceability analysis is performed. In the requirements phase, HAZOP-based safety analysis is performed, and FMEA is performed after the design phase. In the implementation phase, code inspections are performed based on safety-related source code rules. Test and verification after the implementation phase consist of module/unit test, integration test, and system test.

The pass/fail criteria for V&V in the test phase is that the module/unit test must satisfy statement coverage, condition/decision coverage, and MC/DC coverage. The pass/fail criteria for the integration test is to verify interface errors between the modules/units being integrated, and it is important to maintain load balancing so that the degree of integration is not skewed to one side. During the integration process, it is essential to verify that there are no memory leaks. During the system testing phase, error-based malfunction tests are performed to verify functionality, performance, and interfaces and to ensure that there are no potential errors. At the end of the malfunction test, the results of the FMEA are finally synthesized and an incremental safety case demonstration is performed. After the safety case demonstration, the Functional Configuration Audit (FCA) and Physical Configuration Audit (PCA) are performed and the verification is done finally (Figure 7).

This paper concludes that the development and V&V of safety-related software systems requires a multifaceted approach that includes an appropriate development methodology and a comprehensive set of verification and validation techniques. Therefore, the use of JY-development methodology and its verification methodology facilitates the assessment of licensee conformance in safety-related systems. It is an alternative approach to addressing emerging issues and challenges in safety-related software development and verification, and requires continuous improvement and adaptation. In the future, I will study safety-critical software development methodology and its verification and validation in details.