Mechanism requirements: 0 Mechanism requirements: 0.2% uniformity of exposure with 4 mm pre-travel (acceleration phase), 32 mm travel (constant velocity in front of the CCD), 4 mm post-travel (deceleration), limited weight, limited power Mechanism resources: no feedback (although required by UPD during the 1996 Montegrotto Meeting), 53 ms of available power (just the forward travel), the two quadrature encoder channels are in XOR to minimise the electrical lines, 53 ms of available time to collect encoder pulses in s/w nominal mode, about 150 ms available time to collect encoder pulses in s/w test mode (mechanism whole travel lasts about 600 ms), protoflight approach Mechanism behaviour just after qualification (@ FM level): functional problems of keeping locking (of the first blade) and unlocking reliability (by the second blade). Thermal drifts that slightly changes the motor and mechanical parameters jeopardized the driving current waveform that, without changes, drove the mechanism in open loop. Light tightness (performances) problems due to some bounces between the two blades and to the lack of power during the travel back.

What is and what is-not coded onboard OSIRIS DPU The brake was not qualified during slots A-D brake late last year was coded an adaptive dynamics loop Performance evaluation + stochastic adjust The stochastic adjust was never took into consideration (one reason: to change the s/w management in test mode) The new algorithm coded onboard OSIRIS

WAC: shots 372; errors 0 From 2008-09-05T18:04:04.364 to 2008-09-05T20:34:07.358: 372 times, Z (121) CRB: Start WAC exposure 2008-09-05T21:11:15.526: Z (327) PCM: WAC Shutter Off NAC: 72 shots; 23 A errors; 327 aborted acquisitions STEINS fly-by summary

From 2008-09-05T18:00:27.839 to 2008-09-05T18:00:48.300: 7 times Z (120) CRB: Start NAC exposure (Total NAC shots 8) 2008-09-05T18:00:53.934: Z (278) Shutter: Type A error occured - Camera = NAC (Total SHM NAC errors 1); Z (440) Shutter: Blades forced back into home position - Camera = NAC; Z (285) Shutter error recovery succeded 0 (0x0) STEINS fly-by summary

From 2008-09-05T18:04:15.613 to 2008-09-05T18:04:27.715: 3 times: Z (120) CRB: Start NAC exposure; Z (278) Shutter: Type A error occured - Camera = NAC; Z (440) Shutter: Blades forced back into home position - Camera = NAC; Z (285) Shutter: Shutter error recovery succeded 0 (0x0) (Total SHM NAC errors 7) (Total NAC shots 17) Where are the second blade pulses? Second blade missed the encoder zero pulse starting from an advanced position? Looking at blade 1 this seems not to be likely STEINS fly-by summary

From 2008-09-05T18:04:31.001 to 2008-09-05T18:04:34.032: 2 times: Z (120) CRB: Start NAC exposure(Total NAC shots 19) What are those short sequences? Blade 1 fired inside locking? 2008-09-05T18:04:37.296: Z (278) Shutter: Type A error occured - Camera = NAC (Total SHM NAC errors 8); Z (440) Shutter: Blades forced back into home position - Camera = NAC; Z (285) Shutter: Shutter error recovery succeded 0 (0x0) STEINS fly-by summary

From 2008-09-05T 18:25:07.682 to 2008-09-05T 18:27:46.123: 7 times: Z (120) CRB: Start NAC exposure (Total NAC shots 68) Mean repetition rate: - 0.42 shots/s - 1 shot every 2.3 s … 9 minutes before the closest approach the NAC telescope stopped working STEINS fly-by summary – NAC repetition rate

This image had an exposure time of 78ms. Blade 1 was not caught by the locking device, so yet another error type A occurred. The 78ms is smaller than a magic number 80ms that would block the blade 2 being shot in error condition of type A. So, blade 2 was activated and ran into blade 1, which was already on its way back home, actually at a location not far away from the locking device. Blade 2 was in constant velocity and kicked blade 1 INTO THE LOCKING DEVICE WHERE IS WAS COUGHT AND LOCKED. The error type reported was still type A as detected at a given time after shooting blade1 (error condition is checked after 53ms, tbc), but blade 1 was in locking unexpectedly. The onboard software reacted (properly, but not appropriate in this case) on a type A error, performed a slight home push and reloaded the shutter profile. It then did a CRBSync expecting a clean shutter, and found the shutter in error condition. It reloaded the profile again, and the shutter was (of course) still in error. In consequence, the error recovery was signaled not successful and all NAC operation stopped :-(( Why the 327 aborted acquisitions? STEINS fly-by summary – Holger Sierks 25/09/2008 19.42

2008-09-05T18:28:19.130 1 time: Z (120) CRB: Start NAC exposure; Z (278) Shutter: Type A error occured - Camera = NAC; Z (440) Shutter: Blades forced back into home position - Camera = NAC; Z (284) Shutter: Shutter error recovery failed 0 (0x0) (Total SHM NAC errors 23) (Total NAC shots 72) STEINS fly-by summary

We must analyse how many times those phenomena occurred Why the homepush? This forced in the opposite direction the lock mechanism causing a bending force on the flexural pivot! Also activations of the first blade inside the locking would cause similar effects during the deceleration phase We must analyse how many times those phenomena occurred STEINS fly-by summary

Apart from the ‘fatal’ bug it is important to understand why the NAC experienced so many type A errors just getting closer to Steins For this purpose we analysed the NAC frame rate and errors statistics since july 2008-07-11 slot SR99A STEINS fly-by summary – Type A errors

TEST SLOT SR99A: from 2008-07-11T09:14:46. 501 to 2008-07-11T12:33:18 NAC: 127 shots, 2 error type A, 2 error type C Relatively high frame rate … after a while type A errors STEINS fly-by summary – Type A errors

TEST SLOT 99B: data not available TEST SLOT 99C: from 2008-07-24T23:59:46.501 to 2008-07-25T01:10:46.594 NAC: 7 shots, 0 error low frame rate … NO errors STEINS fly-by summary – Type A errors

TEST SLOT 99D: from 2008-07-31T22:29:46.499 to 2008-08-01T00:29:53.450 NAC: 42 shots, 0 error low frame rate … NO errors STEINS fly-by summary – Type A errors

STEINS NAVIGATION: from 2008-08-04T02:09:45.271 to 2008-08-04T13:32:55.507 NAC: 5 shots, 0 error low frame rate … NO errors STEINS fly-by summary – Type A errors

STEINS FLYBY LC1: from 2008-08-20T16:39:45. 271 to 2008-08-21T02:51:55 NAC: 101 shots, 2 error type A low frame rate … few errors STEINS fly-by summary – Type A errors

TEST SLOT STEINS FLYBT LC2: from 2008-09-04T17:29:44 TEST SLOT STEINS FLYBT LC2: from 2008-09-04T17:29:44.520 to 2008-09-05T00:08:15.823 NAC: 79 shots, 0 error Very low frame rate … NO errors STEINS fly-by summary – Type A errors

STEINS FLYBY 05/09/2008 (ANTE 18:00) NAC: From 2008-09-05 T16.39.03.761 to T17.57.11.021 114 shots NAC, 16 error type A, ed 1 error type D. High frame rate … after a while type A errors STEINS fly-by summary – Type A errors

STEINS FLYBY 05/09/2008 (POST 18:00) NAC: From 2008-09-05T18:00:23.548 to 2008-09-05T21:10:26.506: 72 shots; 23 A errors; 327 aborted acquisitions High frame rate … continued just with the same performances in type A errors

NAC motors temperature STEINS fly-by summary – Type A errors

WAC: From 2008-09-05T18:04:04. 364 to 2008-09-05T20:34:07 WAC: From 2008-09-05T18:04:04.364 to 2008-09-05T20:34:07.358: 372 shots; errors 0 Very High frame rate … NO errors

Some data - Slot B very high impact velocity (integer to float bug in the command list sent to OSIRIS)

Possible explanations: Thermal explanations like for example rotor heating not seen due to the ball bearings insulation? Filter wheel interference? STEINS fly-by summary – to explain type A errors

2. To implement the stochastic search There are two ways: 1. To validate the brake 2. To implement the stochastic search 3. To free the impact velocity range from its initial guess STEINS fly-by summary – to solve backtravel openings

To verify the thermal explanation to increasing A errors To verify the NAC SHM integrity (there are strong arguments that indicate the mech is still operational) To verify the number of non foreseen operations the mechanism bore in order to plan the number of testing which depends upon a guess of the life left To verify the fail safe software (frame transfer), has it been implemented and thoroughly tested on board? To verify the thermal explanation to increasing A errors To test on the UPD QM SHM together with MPS STEINS fly-by summary – the way to proceed