Vol.3 No.3 2010
22/60

Research paper : A methodology for improving reliability of complex systems (A. Katoh et al.)−207−Synthesiology - English edition Vol.3 No.3 (2010) of the system development by appropriately applying the systems engineering methods. In this paper, it is not possible to present the degree of reducing the cost and delivery time by the application of architectural design method in the industrial case. However, considering the fact that certain results are obtained for architectural designing, there is a high possibility that the cost and delivery time can be reduced for the system development. For bridge method and model checking, as shown in Table 4, 5 man-hours and 12 man-hours are required for the measurement subsystem and the integrated control subsystem, respectively. Here, we discuss inconsistency of the cooperative behavior detected by conducting model checking through the bridge method. Inconsistency of the cooperative behavior between subsystems can generally be detected in the system test where the subsystems are combined, conducted at the final phase of system development. If inconsistency of the cooperative behavior among subsystems is detected in the system test, large amount of cost and time are required for correcting. Boehm, in Reference[26], analyzed that if the cost of detecting and correcting the requirement flaws at the phase of defining requirement specifications were set as 1, the cost would be 2 in a small-scale system if the requirement flaws were detected in the test, and the cost would be 20 in a large-scale system. Inconsistencies of the cooperative behavior shown in Table 3 are flaws which are highly likely to be missed unless model checking is applied in the phase when the required specifications are defined. Considering the whole system development, the man-hours required for bridge method and model checking are highly cost-effective.6.2 Applicability of this methodologyThe methodology in this research is not specialized to the development of particular technological systems, but it can be applied universally to the development of any technological system. The reason is that in designing a system, achieving a function of the system by finding components which compose the system based on the system specification and having the components cooperate is a common concept for all technological systems. Also, this methodology can deal with unique problems related to the cooperative behavior in an applicable system. The reason is that it has the bridge method where attributes and model checking tools are selected according to the characteristics of the cooperative behavior.However, attentions must be paid in the application of this methodology. This methodology employs model checking to verify whether the cooperative behavior by the components is consistent. Model checking is a method to verify whether given properties are valid or invalid in all possible state transitions which can be achieved by the models using a computer exhaustively. In cases where there are numerous states of the models in model checking, state explosion may occur where model checking does not get completed since the number of state combinations is too large. This means there is a possibility that the verification of the cooperative behavior by model checking may not get completed when the cooperative behavior by the components becomes extremely complex as a result of architectural designing. In this case, it is necessary to conduct re-architectural designing to prevent the cooperative behavior by the components from getting extremely complex, or reduce the number of the states in the models for the specifications related to the cooperative behavior.6.3 IssuesWe are able to comfirm the effectiveness of this methodology on an industrial case study. However, there are some issues which must be solved in the future.The first issue is a problem of the bridge method in this methodology. In bridge method, the properties which must be satisfied by the cooperative behavior are extracted. In general, the properties to be satisfied by a target of model checking are liveness and safety[27]. Liveness is a property where “the verification target will eventually reach a desirable state”. Safety is a property where “the verification target will never reach an undesirable state”. The liveness property is often the specifications which must be achieved Fig. 13 Cooperative behavior model for interface specification between the measurement and integrated control subsystems

元のページ 

page 22

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