• Journal of Korean Society for Quality Management
• /
• v.49 no.3
• /
• pp.269-279
• /
• 2021

Purpose: The purpose of this study was to suggest weapon system specifications for requirements of Condition-Based Maintenance(CBM/CBM⁺). Methods: The military documents and case studies with regard to condition-based maintenance were reviewed. Representative Korea defense specifications of weapon system such as an aircraft, a C4ISR etc. were analyzed and investigated the level of requirement for maintainability was. Results: Condition-based maintenance was defined in both U.S. instruction and Korean directive. While deparment of defense(U.S.) provide a guidebook for CBM⁺, detailed instruction was not sufficient for Korean. Ministry of national defense(ROK) define the CBM⁺ by means of IPS element which should be developed along with the system development. The maintainability was barely included in Korean defense specifications, except for BIT(Built-in test) function. As a first step for defining the condition-based maintenance requirement in defense specification, this study suggests a standard form for data needed to acquire according to types of system, fault, failure, and so on. Conclusion: The empirical researches on CMB/CBM⁺ with domestic weapon systems are not enough, and a logic which leads the maintenance strategy to CMB/CBM⁺ is not solved. Through technical researches and institutional improvements including this study, we hope that condition-based maintenance would be fully established in the Korean defense field.

• Journal of KIISE:Software and Applications
• /
• v.34 no.9
• /
• pp.773-784
• /
• 2007

Aspect-Oriented Programming (AOP) has focused on improving the modularity of the crosscutting concerns. The existing AOP methodology has been mainly focused on the implementation method of programs and thus developer-oriented concern extraction and development were performed. Recently, many studies for applying AOP to the entire software development processes ranging from requirement analysis to design and implementation are being conducted. But specification methods having consistency from the initial phase of concern extraction to implementation phase are not sufficient. In this paper, we have presented the specification of crosscutting concerns so as to solve these problems. The specification of crosscutting concerns provides guidelines and specification from the requirement analysis phase to the process of converting extracted crosscutting concerns to codes. This method reduces the gap to the process of mapping extracted crosscutting concerns into a single class and thus enhances program development and understandability. In addition, it raises program reusability, maintenance and extensibility by enhancing traceability.

• Journal of the Korea Society for Simulation
• /
• v.27 no.2
• /
• pp.61-69
• /
• 2018

As the technology of information and communication has developed over recent years, an embedded system is applied in multiple industries and becomes more complicated. For this reason, embedded system development cost and time are also increased. For decreasing the cost and time, this paper suggests requirement evaluation method for concurrent development of an embedded system based on Discrete Event System(DEVS) Formalism. This paper proposes a method of describing the requirements specification in the form of DEVS atomic model. Also, the paper proposes the evaluator model that compares evaluation target system and the requirements model that is an implementation of requirement specification and proposes the evaluation method using them. In addition, we propose a method to utilize the requirement model created for requirements evaluation in the concurrent development process of the embedded system. As the case study, this paper proceeds requirement evaluation of Kinect depth data processing system.

• Proceedings of the KSR Conference
• /
• 2009.05a
• /
• pp.1959-1962
• /
• 2009

In this paper, we derive the hazard which is a criterion of safety assurance by PHA for the ATP equipped in Korea Tilting Train. The ATP onboard equipment in Korea Tilting Train was introduced as ETCS Level l(which is ETCS specification). Also, the ATP trackside equipment was introduced as a ETCS SRS(System Requirement Specification) 2.2.2 and it has a target for commercial operation in 2009 late. In IEC 62278(EN50126), it recommend of PHA to derive a hazard of target system in concept establishment step and estimate if it can control as a tolerable level and then derive safety case to control the hazard by lifecycle. Therefore, we indicate the hazard using criterion of safety assurance by PHA using FRS (Functional Requirement Specification) 5.0. which is a upper criterion than SRS. The hazard of ATP onboard equipment derived in Korea Tilting Train will be able to use as ATP functional hazards of unified onboard equipment in G7 which is a multiple unit and preliminary hazards of ATP onboard equipment in NEL drived by Korail.

• Proceedings of the Korean Information Science Society Conference
• /
• 1998.10b
• /
• pp.579-581
• /
• 1998

소프트웨어 개발에서 나타나는 많은 오류는 요구 사항에 대한 정확한 이해의 부족에서 기인된다. 따라서 분석 단계에서 요구사항을 정확하게 나타내는 활동은 전체 소프트웨어의 신뢰성에 큰 영향을 미치게 된다. 요구 검증은 요구 분석 활동에서 산출되는 정보가 요구 문서의 정보를 바르게 나타내는가를 검증하는 활동이다. 본 연구에서는 객체 지향 소프트웨어의 개발에서 요구 검증을 수행하기 위해 OFL(Object-oriented Formal Language)과 질의 추출을 적용하였다. OFL은 객체 지향 형식 상태변이사항(Formal state transition specification)으로 형식 언어가 기자고 있는 명확성을 유지하며 분석 활동의 결과를 체계적으로 제시한다. 이러한 결과와 요구 문서와의 비교를 위하여 질의 추출이 수행된다. 이는 질의를 통하여 요구 문서에서는 나타나는 정보를 체계적으로 정리하여 개발 의뢰자가 제시한 요구 사항과 개발자가 제시하는 요구 사양간에 일치성과 완전성이 존재함을 검증한다. 이러한 요구 검증은 요구 사양의 신뢰성뿐만 아니라 개발되는 소프트웨어의 신뢰성을 향상시킨다.

• Journal of the Korean Society of Systems Engineering
• /
• v.10 no.1
• /
• pp.81-86
• /
• 2014

Systems Engineering application focused on requirement definition and management for SURION System Development Project is described in this paper. To perform the development process effectively based on systems engineering processes; Requirements Definition, Design Review, Configuration Management, Quality Assurance, Data Management, are applied in this project. In this processes, the Stakeholder's Requirements are transferred to Specifications verified with design reviews, prototyping inspections, and integration tests. All engineering data, especially verification plan & results are recorded, and traced to each requirements of system specification in Surion database. Therefore, it could be assured that all requirements of specification are evaluated and verified successfully in Surion Project.

• Convergence Security Journal
• /
• v.5 no.3
• /
• pp.67-73
• /
• 2005

Security requirements must be defined well to reduce software vulnerabilities in requirement specification phase. In this paper, we show how to specify security requirements in structured manner for object-oriented development methodology. Our method specifies security requirements through four phases: defining security objectives, identifying the threat, construct attack tree, and specifying security function. This method would help developers to specify security requirements and functions which software have to possess clearly and systematically.

• Proceedings of the KSR Conference
• /
• 2001.10a
• /
• pp.35.1-40
• /
• 2001

This study is on the behavior analysis which can define and verify a system requirement through a behavior diagram for High speed rail system. The model considered in this study is limited to the preconditioning control of the control system specification for HSRS. To build an executable model, requirements should be decomposed first into leaf node requirements. The behavior model is composed of input, output, and functions which are linked with leaf node requirements. It is important that a single requirement must specify a single Auction. Using the developed executable model and the traceability between requirements and functions, this study found out a lot of static and dynamic inconsistency, missed and derived requirements. This is to develop and executable behavior model to do functional analysis and be able to verify the integrity of a specification.

• Nuclear Engineering and Technology
• /
• v.31 no.1
• /
• pp.58-67
• /
• 1999

The purpose is to produce a model of nuclear reactor trip logic caused by the steam generator water level of Wolsong 2/3/4 unit through an activity chart and a statechart and to produce C language automatically using Statechart-based Formalism and Stalemate MAGNUM toolset suggested by David Harel Formalism. It was worth attempting auto-generation of C language though we manually made Software Requirement Specification(SRS) for safety-critical software using statechart-based formalism. Most of the phases of the software life-cycle except the software requirement specification of an analysis phase were generated automatically by Computer Aided Software Engineering (CASE) tools. It was verified that automatically produced C language has high productivity, portability, and quality through the simulation.

• Proceedings of the KIEE Conference
• /
• 2003.11c
• /
• pp.802-805
• /
• 2003

The aim of this paper is to provide a guide to those methods of train detection which are available, or are likely to become available, to the designer of train control or other relevant systems. In broad terms, train detection may be defined as the process of generating information which describes the location and movement of trains. Train detection information is difficult to define in isolation. Consider, for example, the train detection information required in a modern train control system. This may vary considerably : in a future high performance train control system, it might be necessary to know the precise position, direction of movement, speed, and possibly even the acceleration or braking, of all trains in the control area : in a less demanding application, it might be sufficient to know only the location of trains in terms of the occupation of sections of track.