Vol.3 No.3 2010
26/60

Research paper : A methodology for improving reliability of complex systems (A. Katoh et al.)−211−Synthesiology - English edition Vol.3 No.3 (2010) Society for Aerospace and Space Sciences, Institute of Electrical and Electronics Engineers, Inc. (IEEE), and American Institute of Aeronautics and Astronautics (AIAA). In this paper, was in charge of research strategy planning and research integration.Discussions with Reviewers1 Novelty of the issue and outcomesQuestion (Kanji Ueda, AIST)In chapter 2, you say the reason for synthesizing the methods of different research or technological fields is that you can expect to produce a new research or technological field as some new technologies are generated from the synthesis. What kind of results did you obtain from this research?Comment (Motoyuki Akamatsu, Human Technology Research Institute, AIST)This paper claims novelty, but the readers outside of this specialty cannot understand immediately whether it is novel. I assume that there had been methods proposed to improve the reliability of the system, and I think you can emphasize the novelty if you explain the situation before this research was carried out. Similarly, I think you should explain why such critical technology was never pursued before, and why it had been difficult.Answer (Atsushi Katoh)I would like to explain the background of this research by focusing on the cooperative behavior by the system components. Normally, the cooperative behavior by the system components is verified in the system test that is conducted at the final phase of system development. When any inconsistency of the cooperative behavior is detected there, it is necessary to return to the upstream of the system development for correcting, and correction is often quite costly. Also, re-designing in the final phase may compromise the reliability of the system. Therefore, the cooperative behavior by system components must be designed and verified thoroughly in the upstream of the system development. At that point, there was no proposal for a methodology to achieve this. The reason is that the cooperative behavior by system components was not viewed from the perspective of system reliability, and the incorporation of system quality in the upstream of the system development was a relatively new concept. I shall add these points in chapter 1.As results of conducting this research, the following four outcomes were obtained. First is the establishment of this methodology where the system specifications are decomposed into the component specifications and interface specifications among components for consistent cooperative behavior. Second is the clarification that bridge method is needed to synthesize architectural design method and model checking, and the presentation of an actual example for the bridge method for the cooperative behavior. Third is the expansion of the ranges of application and research of model checking, by applying the method that was mainly used in software development to system development. Fourth is the proposal of this methodology to the robot industry.2 Cooperative behaviorComment (Kanji Ueda)You use the expressions “cooperative behavior by the components” several times, but I think the general readers may have difficulty understanding the meaning. Also, you use “consistency/inconsistency of the cooperative behavior” as self-explanatory terms. Please state the definition or the meaning of the cooperative behavior, and provide explanations.Comment (Motoyuki Akamatsu)You do not describe the means for determining the attributes of the cooperative behavior, extracting the properties to be satisfied by cooperative behavior, and for considering safety. Therefore, I don’t think the robot engineers, for example, can see whether they can use this. I think you should provide explanations that give some hints for the people of the robot industry to use this methodology.Answer (Atsushi Katoh)In this paper, the cooperative behavior by components is defined as “a cooperation with processings of the system component and the other system components through the interface among components”. The consistency of cooperative behavior is defined as the state where “a consistent implementation of the cooperative behavior by the components in correspondence to the system specification is conducted”. The inconsistency of cooperative behavior is defined as the state where “the definition of the consistency of the cooperative behavior is not satisfied”. These are added to chapter 1.The attributes of the cooperative behavior are determined based on the properties to be satisfied by the cooperative behavior and the specifications related to the cooperative behavior. For the measurement and integrated control subsystems in the applied case, we were concerned about the lacks in the messages and processings of the specifications related to the cooperative behavior. Also, there were temporal limitation specifications such as within 100 ms and timing of messages and processings, among the properties to be satisfied by the cooperative behavior and the specifications related to the cooperative behavior. Therefore, the two points presented in subchapter 4.2 were determined as the attributes. We will add these to section 5.2.2.The properties that must be satisfied by the cooperative behavior are extracted using the traceability matrix that summalizes the correspondence between the system specifications and the component specifications obtained by decomposing the system specifications.Confirming safety of the cooperative behavior is the topic of this research. Safety means a property where the system will never reach an undesirable state. Since it is difficult to identify “all the states where the system is undesirable”, it cannot be denied that there may be a fault in the safety confirmation for the cooperative behavior. We plan to investigate the solution to this issue by combining a safety analysis method such as fault tree analysis (FTA) with this methodology.3 Selection of methodsQuestion (Kanji Ueda)There are many expressions of “according to IEEE 1220…”. What is its relationship to the methodology developed in this research? Also, the reason why you employed IEEE 1220 is not clear.Comment (Motoyuki Akamatsu)Please explain what other methods there were of system design methods other than architectural designing. Please also explain methods other than IEEE 1220 that you did not employ for architectural designing. Also, to clarify the scenario for selecting IEEE 1220 among several other architectural design methods, it will be easier to understand if you describe what disadvantages there were in the other methods.It is explained in chapter 1 that model checking is a method to exhaustively verify the models that express the state transitions of the system. Please explain whether model checking method used here was originally developed in this research or is an application of an existing method.It is written that the checking tool based on finite automaton was selected as the model checking tool, and you describe the

元のページ 

page 26

※このページを正しく表示するにはFlashPlayer10.2以上が必要です