Nozomi in perspective, Revisiting the causes of failure Options

[pandaneko]

http://www.mext.go.jp/b_menu/shingi/uchuu/...ts/04061101.pdf

Above pdf file will be translated for aspiring students in aeronautics, control engineering etc. so that in future lay people like me will be able to enjoy planetary scenes and events without worrying about failures.

The overall title is "Looking into the causes of failure and trying to find the right measures to take for the future with respect to the 18th scientific satellite (PLANET-B ) not inserted into Mars orbit as planned" and it is dated 21 May 2004.

This file is very much detailed at 1.1 megabytes and the number of pages is about 40, I think. In addition, I will be translating 3 more files after this particular file. They will be;

1. ISAS file with views and comments on the failure
2. Another ISAS file, a newsletter written out in a series of 4 individual letters.
3. JAXA file, which is a press release and it is a very concise document with just sufficient details.

Re concise link making I tried a few times, but I simply failed and all the links will be fully pasted out as required.

Pandaneko

[pandaneko]

http://www.mext.go.jp/b_menu/shingi/uchuu/...ts/04061101.pdf

above for ease of reference

page 31


(3) Dealing with imports

There are cases where we have to procure imported items for space use with scientific satellites such as their components and devices because they are not produced in this country. With these imported items even if information on verification tests and flight records against our specs can be obtained from manufacturers it may not always mean that detailed internal structural information is available.

In these cases of limited availability of information on internal structure of devices and their electrical interfaces we must ensure that not only verification tests from user's point of view are carried out but also we must give utmost priority to the issue of seperating out failure causes.

Furthermore, we must, in the event of import troubles, make sure to cooperate with the manufacturers to clarify the status with a view to coming up with approapriate measures for rectifying the situation not just by oursleves but also with the cooperation of all organisations involved.

(4 ) Seperating out failure causes

Space systems cannot exclude the possibility of mulfunctions completely. Nor can we expect to be able to carry out repairt works in orbit. For these reasons we mus ensure that partial mulfunction by onboard devices will not lead to a total mission loss. We lay out points to note in trying to seperate out failure causes as follows.


① About the degree of seriousness of mulfunction in hand we must be able to evaluate the seriousness of possible repercussions to the system as a whole by making use of evaluation methods such as Failure Mode Effects Analysis (?, P)(FMEA) and Failure Mode influence fatality analysis (FMECA) so that the trouble in hand will not spread to other important systems by giving preferential priority to the failure cause seperation.

② Based on the priority judged by ① above we must make selective (given seriousness, repercussions and importance of the troubles) judgement on the possibility of mulfunction seperation and containment such as adoption of redundancy, seperation of power sources, building in of protective resisters etc.

③ With those items whose functional loss will not lead to serious faitality or those which are used only at the time of launch etc., that is to say, those items whose mulfunctions will not spread into secondary fatalities and therefore do not need our utmost attention we must select as much as possible the least troublesome failure cause seperation measures (such as the use of protective registers and installation of switches etc.).

(5) Trouble shooting by software

In the case of Nozomi our operation continued even after the accident in 2002. In fact, our continued operation of Nozomi lasted for 5 years from the launch in July 1999 to December 2003. This was made possible by several factors such as an improvement made on autonomous function and re-writing of data handling unit (DHU) software etc.

- 31 -

Being able to re-write the software after launch from the ground is an extremely effective measure to deal with various troublesome situations as we can pliably deal with different events by making the on-board devices carry out different functions. Naturally, similar capability has been adopted for the scientfic satellites which are in the pipeline and it is thought that changes in hardware functions by software re-writing will be popular from now on.

On the other hand we should note that use of unverified software is very dangerous. Therefore, it is imperative that we conduct sufficient ground tests with each of the software functions in order to establish reliability. Also, in the event that on-board software re-writing is deemed paramout we must first thoroughly check the safety of re-writing with a flight model and its electrically equivalent functional devices. Actual re-writing will have to be made based on the result of these ground tests.

end of page 31

P