Detlef Koschny Research and Scientific Support Department ESA/ESTEC Interfaces to RSOC Detlef Koschny Research and Scientific Support Department ESA/ESTEC Detlef.Koschny@rssd.esa.int Introduction Reminder: Rosetta Ground Segment Architecture Interface in the different planning cycles The ftp interface to RSOC File naming conventions What happens after submission?

Architecture during individual commissioning Experiment User Manuals Experimenter supports FCP execution RMOC executes FCPs Project Scientist approves uplink FCP = Flight Control Procedure = piece of paper with list of telecommand s Additional tasks of the Science Operations Team: Convert PI input into Excel files for ESOC Support overall planning Generate Scenario Parameter Lists in the case Pis need pointing in their individual commissioning Provide computer interface for passing Lander Operation Request files and convert them to PORs

Architecture during nominal science operations Flight Control Team (FCT) Ground Segment Management SOC Management RSOC POR File Flight dyn. Request files Science ops planning Timeline Integration Science Sequence Assembly Flight Dynamics Team (FD) Stations and Facilities Management Command history Pointing modes, trajectory Architecture during nominal science operations Trajectory, attitude Telemetry Data Archiving / Handling Raw data Data Systems RMOC Science communications, databases Raw data, auxiliary data, h/k Raw and Cal. data DDS Request Raw data Operational Requests, Pointing Requests Lander Operations Plan PI Teams EPS (tbd) Sequence Builder Data Analyst POR = Payload Operational Request file RMOC = Rosetta Missions Operations Centre @ ESOC RSOC = Rosetta Science Operations Centre @ ESTEC DDS = Data Disposition System Experiment Sequence Building Experiment Data Analysis Experimenter teams

Interfaces in the different planning cycles - I Planning cycles and concept was described in SWTs/SOWGs. Here just a summary (for nominal comet ops – for cruise ops similar, but different time scales): Long-term planning (several months – years) Define science themes Define overall science priorities and top-level timeline Define standard observation sequences Ensure proper modelling of the instruments at RSOC Medium-term planning (monthly) Define trajectory and pointing skeleton Check resources on top level Have “preliminary ITLs” available, based on standard observation sequences, e.g. exposure times still open Short-term planning (weekly) Final ITL files with all details to RSOC RSOC does final resource and constraint check Sends final POR to RMOC to add s/c commands – iterate when conflicts ITL = Input Timeline

Interfaces in the different planning cycles - II Long-term planning (several months – years) Interface is text in User Manuals, emails, discussions in meetings, telecons. Medium-term planning (monthly) For trajectory and pointing: submit Scenario Parameter Lists (SPL) to RSOC, Word template, currently done via email “preliminary ITLs” currently done via email, will go to ftp interface (see next vu-graph) Short-term planning (weekly) Final ITLs via ftp interface Database maintenance Database change request via ftp interface Software maintenance Software change request and associated patch via ftp interface

The ftp interface to RSOC Described in the RSOC to Experimenter ICD, RO-EST-IF-5010/1a, 15 Apr 2003 Electronic inputs from Experimenter teams, e.g. experiment software patches, shall be sent as computer files using the FTP application to the RSOC FTS computer. Use the following procedure: ftp rodds.esa.int username <press enter> password <press enter> cd requests_to_RSOC put filename.ROS filename.TMP rename filename.TMP filename.ROS quit   filename shall follow the FTS convention ffff_sordes_txxxxxxxxxxxxxx_vvvvv.ROS FTS = File Transfer System

File naming convention filename shall follow the FTS convention FFFF_SORDES_Txxxxxxxxxxxxxx_vvvvv.ROS FFFF: File type. Most important one: OIOR = Orbiter Instrument Operations Request, I.e. an ITL file SOR: Source. For OSIRIS always ‘PI7’ DES: Destination, always ‘RSO’ T: type, always ‘D’ xx…xx: Description field – see ICD for details VVVVV: ‘Version’ number – really a sequential count number. Needs to increase by one for each submission .ROS – always ‘ROS’ for Rosetta (.VEX for Venus Express)

What happens after submission? The input file is picked up by the “Operational File Request Acknowledger (ORF-A)”, a skript that Checks the file name for correctness For OIOR files, checks whether they follow ITL syntax Generates an acknowledgement (file type ‘ACKN’), containing a confirmation of the receipt of the file and possible error reports ftp’s the acknowledgement back to the experimenter’s computer Generates a log file entry which can be viewed via a web-based interface When the deadline for the inputs is reached, RSOC personnel will: look at the files consolidate all inputs from the teams perform resource checking iterate if needed with experimenter teams; generate a POR file, submit it to RMOC Uplink to spacecraft, and do it! Downlink data available via DDS RSOC products submitted are also available via the DDS