I started my career at Lockheed Missiles and Space and my job was satellite payload analysis as well as failure modes and recovery methods to ensure getting the data back.
It was less 'formal' (if I can use that word) than methods available today, but was nonetheless meticulous and involved knowing every circuit, its function, how it could fail, and what that failure would do to the rest of the systems.
Good for anyone who later in their career had to debug of any type of system.
Keep up the good work!
Again, a great series of articles! I remember trying to debug 15x15in pcbs in an array processor prototype with suspect boards on 15" extender boards. When running at full speed sometimes it would not work (had to run 1/2 clock speed - really glad we had designed in that!). Debug of completed systems is always a challenge but more so with compact systems!
Hi Sanjib, I would say that we did not use these formal methods. Thinking about them, these too should be a lesson learned. It takes someone on the team with this kind of knowledge to help lead a volunteer team. Thanks for the suggestion!
HI Steve, thank you for sharing the article! It gives me a deeper knowledge on ARISSat-1's power system. I saw the information about the failure modes of the battery you are talking about.
Have you also used any of the traditional failure analysis tools such as FMEA, Fault Tree Analysis to organize the actions required to build the recovery mechanism for different probable failure modes for all the sub-systems?
Hi Sanjib, We did think about failure modes and how to recover from them. Tony Monteiro (AA2TX) wrote about the power system in the Jan/Feb 2011 issue of The AMSAT Journal. In the article he describes the failure modes of the battery. The article is available at http://tinyurl.com/3f72xvy.
Hi Steve, just curious to know ... did you do some kind of failure modes and effect analysis (FMEA) at the beginning of the design phase of the project? Were the modes of battery failures not considered?
Anyways, I think now it becomes part of integrated knowledge base to avoid such possibilities in future. All the best for next one! :)
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...