JUICE Pointing Tool

The JUICE Pointing Design Tool or JUICE Pointing Tool (PT) is a web-based tool supporting the assisted creation of pointing requests for the JUICE planning activities.

If you want to start using the Pointing Tool you can jump directly to Working with PT.

References

There are a number of documents, which might only accessible to private users, that provide more information on PT and that can be useful or that have been used as reference. These are listed hereunder:

CIT01

Rosetta Science Ground Segment Flight Dynamics Pointing Interface, RSGS-FD-PT-ICD, Issue 3, Revision 4, July 2, 2014.

CIT02

Mission Planning Assumptions Document, JUI-ESOC-MOC-TN-002, Issue 1, Revision 3, February 17, 2021.

CIT03

NAIF Quaternions White Paper, November 30, 2003.

CIT04

SPICE-Enhanced Cosmographia User Guide.

CIT05

The VizieR database of astronomical catalogues, Universite de Strasburg/CNRS.

Overview

The Pointing Design Tool is intended to support detailed operational scenario analysis by supporting the definition of PTR snippets based on the OSVE (Operations Simulations and Validation Engine) module. PTR stands for “Planning Timeline Request” and is the term used in the ESOC jargon to define the product generated by the Science Operations Center (SOC) for a planning period (typically the Medium Term Planning period, MTP) and represents an attitude that fulfils science as well as the Fight Dynamics (FD) requirements.

The OSVE module is a C++ library that provides the modular functionality for EPS (experiment Planning Software) and AGM (Attitude Generator Module) as developed for the MAPPS software. PT uses the AGM of OSVE.

PT and allows to visualize in a 3D environment the geometry of an attitude profile defined or loaded by PT in a very similar fashion to the SPICE-Enhanced Cosmographia Tool ([CIT04]) with obvious limitations but also with the advantage of being able to run it with a web browser as a front-end to the software and data managed by the JUICE SOC.

Detailed Scenarios

Detailed Scenarios are extracted from the outcome of a science segmentation plan and are developed as detailed sizing case analysis for science operations: for specific challenging sections of the segmentation, in-depth analysis is needed in order to refine resources assumptions (attitude, power, data volume…). Those detailed analysis, as similar as possible to the real ones, performed at observation level are done in collaboration with the instrument teams and are integrated in the trajectory segmentation, ensuring its feasibility.

For these detailed scenarios an in-depth design and understanding of the JUICE S/C attitude is fundamental for the design of the science observations and high-level resources analysis. For each scenario we will therefore define an attitude timeline.

The Attitude Timeline

The JUICE S/C attitude timeline is defined by a list of pointing blocks (also know as PTR snippets) in pseudo-XML format. Each snippet is represented by a child element block. Each of these blocks defines the S/C attitude for an interval of time. These blocks must be in order of increasing time and cannot overlap.

In general, There are three types of pointing blocks:

1. observation-blocks: used to implement scientific observations

2. slew-blocks: used to transition from one pointing block to another

3. maintenance-blocks: used to perform Trajectory-Correction-Manoeuvre (TCM), Wheel-off-Loading (WOL), slews, or navigation slots.

Observation Blocks

The attitude in an observation block is defined by help of a basic pointing and optionally an offset rotation or derived pointings. It is beyond the scope of this document to provide a detailed pointing design guide or format description; in fact the PT will assist you in the process of designing the pointing snippets. Nevertheless a brief summary of the available pointing types is provided hereunder.

For each basic pointing a boresight is aligned with a target defined relative to inertial frame. The following basic pointings are available:

• inertial: the boresight is aligned with a fixed vector given relative to inertial frame.

• track: the target is given by a solar system object or landmark.

• limb: points the boresight to an user-selected point relative to the limb of the target.

• velocity: points the boresight along the velocity vector of the S/C relative to the target.

• specular: points the boresight to the specular point wrt. Earth on an elliptical surface defined relative to the centre of the target.

• terminator: points the boresight to the point on the terminator that is in the target-sun-S/C plane and visible from the S/C.

• illuminatedPoint: points the boresight to an illuminated point of the target surface. The illuminated point is the mid-point (in terms of angle as seen from the S/C) between a point on the terminator and the illuminated limb. The point on the terminator and limb are chosen in the target-sun-S/C plane.

If a basic pointing is implemented together with offset rotations it is often required to power-optimise the attitude after the offset rotation is performed. The generic way to do this is by using the derived pointing phaseAngle (see details below) or implementing it with the default settings by appending pwropt to the pointing type.

The power optimised roll places the S/C +Y axis at a certain angle relative to the S/C to Sun direction. The angle is optional. Its default value is 90 degrees. The S/C +Y axis is along (i.e. has positive projection on) the cross product of boresight and S/C to Sun direction, if the parameter yDir is set to true. For yDir set to false it is towards minus the cross product. The default value for yDir is set to true.

It is recommended that this phaseAngle representation is only selected, when the sun direction is between 30 degrees and 150 degrees from the inertial pointing direction (otherwise the pointing can have high rates).

An example of an Europa tracking pointing in a Planning Timeline Request file is provided hereunder:

<prm>
  <body>
    <segment>
      <data>
        <timeline frame="SC">
           <block ref="OBS">
             <startTime>2030-10-31T03:40:00</startTime>
             <endTime>2030-10-31T04:15:00</endTime>
             <attitude ref="track">
               <boresight ref="SC_Zaxis" />
               <target ref="Europa" />
               <offsetRefAxis ref="SC_Xaxis" />
               <offsetAngles ref="fixed">
                 <xAngle units="deg">0.</xAngle>
                 <yAngle units="deg">0.</yAngle>
               </offsetAngles>
               <phaseAngle ref="powerOptimised">
                 <yDir>false </yDir>
               </phaseAngle>
             </attitude>
             <metadata>
               <comment>Track PowerOptimized Offset C3.0</comment>
             </metadata>
           </block>
        </timeline>
      </data>
    </segment>
  </body>
</prm>

Optionally offset rotations around two axes can be applied to basic pointings (as shown in the example above). For this the parameter offsetAngles and offsetRefAxis can be provided. These parameters are provided as child element of the same attitude element in which the basic pointing is defined. Fixed offsets and raster to implement multiple offsets in a single block, and scans can also be defined align with custom offsets.

Finally, you can also define Derived Pointings; an attitude relative to another attitude.

PT helps you to build these observations blocks either as individual pointing snippets or as a series of pointing blocks interleaved with slew blocks.

For more information on pointing design see [CIT01] –if available to you– and/or ask the JUICE SOC (juice_soc@sciops.esa.int).

Slew Blocks

An attitude slew is implemented by inserting a slew block in the PTR. A slew block must always be placed in between two observation blocks. The duration of slew blocks is defined implicitly by the end time of the previous observation block and the start time of the following observation block. A slew block has the syntax:

<block ref="SLEW"/>

Slews –and observations– have a minimum duration of 5 minutes as per [CIT02] and a given required duration as defined per OSVE/AGM simulations depending on the pointing types and the current modelling of the S/C AOCS (Attitude and Orbit Control System) sub-system. PT allows you to not define the end time of the previous observation and/or the start time of the following observation block in order for it to calculate the optimal slew duration.

Constraints for a PTR

A number of S/C operational constraints as defined by Flight Dynamics apply to science operations such as attitude rates for Reaction Wheels (RW) speeds and torques, attitude errors, relaxation times, MGA constraints, etc. Constraints on times and durations do also apply.

Due to its connectivity to OSVE/AGM PT will perform a number of these checks and they will be reported.

Tool Audience

The main audience of PT are the Instrument Teams Scientists and the SOC Operations Scientists involved in the detail scenario planning and science observations definitions.

The Operations Scientists serve as first users of the functionalities developed by the SOC such as the PT.

Accessibility

The PT is accessible from the JUICE SOC Website in Science Operations Planning Tools > Trajectories > Crema X Y > Pointing Tool. It is also available at the JUICE Core System Toolkit menu in the Pointing Tool panel. The Pointing Tool is public.

The Pointing Tool is also programmatically accessible with a REST-API protocol. More information on how to use the Pointing Tool REST-API is provided in Pointing Tool/AGM REST-API

User interface

The PT user interface is divided in a top horizontal menu bar, a left vertical menu and the scene window. These elements and their functionalities are described hereunder.

Top Horizontal Bar

The top horizontal bar provides a number of top-level PT functionalities. On the leftmost side, the Pointing Tool name resets the Pointing Tool and pops-up the window to select the JUICE Trajectory to work on. Currently different crema trajectories are available as defined under the JUICE SPICE page.

Next to it a button displays or hides the left vertical bar and on the right side of the bar a number of icons are available. A moon icon indicates the bodies included in the simulation and an info button provides access to this document and to the AGM definitions used by PT. These definitions might be helpful to write and edit PTRs with PT.

Whenever a PTR is generated and submitted to the PT, two extra icons will appear on the rightmost part of the Top Horizontal Bar: The info icon, that will provide the OSVE logging messages, and the CK/PTR download button, that will allow you to download locally the SPICE Camera-Matrix kernel (CK) providing the attitude in SPICE format for the generated PTR and the Resolved PTR. See The Resolved PTR and PTR to CK, now what? for more information.

Also, after a PTR is generated, the moon icon will provide information of the JUICE-Moon distance for each simulation step.

In addition when a PTR is generated or on the works, the info button provides redundant information for the XML PTR, and a tab to download the SPICE CK file and the Resolved PTR.

Finally, the rightmost button JUICE provides a summary of the information of the SPICE configuration in use (Meta-kernel and SKD version) and the scenario start and end times.

Left Vertical Menu

The left vertical menu is expandable and contains a number of options that are grouped in three themes:

1. Scene Request: Provide the options that will generate the displayed scene.

2. Views: Allows to change the viewpoint of the displayed scene or choose the to display the geometry data.

3. Scene Items: Provides a list of elements to be displayed in the scene such as fields of view (FOV), bodies, grids, stars, etc.

Note

The Left Vertical Menu might not be fully visible depending on your browser window size, if so, you will be able to drag it horizontally with your mouse.

Scene Request

There are three options to request a scene for the pointing tool:

• Default Attitude

• PTR Editor

• Attitude Editor

Note

The scene will always consist of a simulation of 100 steps. The size/duration of these steps will be defined by the duration of the requested pointing.

Default Attitude

The Default Attitude allows you to display the JUICE S/C default attitude for a given time. You have two entries: one for the Start Time and another one for the simulation scene step duration (in seconds). The default time step is 60 seconds. The simulation “Finish Time” will correspond to the Start Time plus the selected step size times 100. You can either select the Star Time from a calendar or input as text.

The default attitude corresponds to the attitude implemented by the SPICE kernels.

PTR Editor

This is probably the most useful feature of the PT and changes the visualization display for an editor that allows you to create your own Planning Timeline Request file, edit it and simulate it. By default the PTR Editor contains the skeleton of the fields of the PTR:

<prm>
  <body>
    <segment>
      <data>
        <timeline frame="SC">

        </timeline>
      </data>
    </segment>
  </body>
</prm>

The editor allows you to perform a number of actions with the blue icons on the top left:

• Open PTR: Allows you to open an already existing PTR in the editor.

• Save: Allows you save the PTR from the editor

• Clear Editor: Clears the blocks written inside the PTR skeleton and restores the skeleton if need be.

• Show/Hide Invisible Characters: Allows you to show or hide the invisible characters from the editor.

The PTR editor has a search functionality by typing Ctrol/Command + f.

The most interesting feature of the editor is its autocomplete feature, especially for pointing blocks. Whenever a letter is typed a list of attributes and keywords is displayed. Some of these keywords are pointing block types – track, track_pwopt, inertial_pwopt, etc. –, and when selected in the context menu, the full template of the pointing block will be provided. By doing so, it is very easy to define the PTR without having full knowledge of the PTR syntax. By selecting one of these templates and changing the attributes of interest it is fairly easy to build a PTR.

The PTR editor will also show syntactical warnings and errors on its left side, by hovering the mouse over these icons, a detailed message will be provided with a description of the issue.

In addition you can choose the Visualization Time Step by editing the value in the text box next to the Submit button.

Below the Submit button there is a box to select the Calculate Power option. By checking this box, the Pointing tool will provide a plot that compares the available power assuming a power-optimised Solar Array orientation with the default attitude (included in the meta-kernel in use). More information is provided in

Finally at the bottom of the editor the Submit button allows you to calculate the attitude profile defined by the PTR and visualize it in the scene window (that replaces the editor).

If the calculation raises an error, the editor will prompt it in a red text box: OSVE problem: Cannot generate attitude and the messages provided by OSVE will be provided on a table underneath it. These messages can be downloaded.

An example of the syntax for a Jupiter power-optimized track pointing is provided hereunder:

<block ref="OBS">
   <attitude ref="track">
      <boresight ref="SC_Zaxis"/>
      <target ref="Jupiter"/>
      <phaseAngle ref="powerOptimised">
         <yDir> false </yDir>
      </phaseAngle>
   </attitude>
   <startTime>2032-07-17T10:17:57</startTime>
</block>

Attitude Editor

The Attitude Editor allows you to provide an attitude profile with time tagged quaternions or to export the result of the submission of a PTR from the PTR Editor or from the Default Attitude as time tagged quaternions. The attitude editor follows the following format: date, qx, qy, qz, qw. The date is UTC ISOC Zulu time, e.g. 2026-05-10T23:23:41Z.

It is highly unlikely that you will write your own quaternions out of the blue, therefore this option is either focused on exporting them as the result of a PTR submission and by using the Save icon; the central icon on top or by pasting or uploading the quaternions generated from another source or a previous session of the PT by using the first icon at the top Upload a CSV file. There is also a Clear button on the right to clear the table of quaternions.

Finally there is also a Visualize button at the bottom of the editor that will display switch to the display window the current attitude.

Note

If you want to know more about quaternions we recommend reference [CIT03].

Views

The next item of the Left Vertical Menu is are the Views. Whenever a PTR is submitted and the display window shows the simulated JUICE 3D geometry, a number of viewpoint options are provided:

• Pointing View: Provides a display panel view from the SC +Z axis co-aligned with the theoretical boresight of most of the instruments that allows to also visualize the instruments FOVs.

• Spacecraft View: Provides display panel view centered in the SC from which we can see the SC model and that allows us to rotate around the SC center facilitating the interpretation of the context geometry.

• Geometry Data: Switches the display window to the Geometry Data Control panel.

Geometry Data

The Geometry Data Control panel provides a number of plots to be visualized for the time window defined by the PTR. This panel is still in a beta state and is planned to be enhanced. For the time being it allows to display distance and phase angle plots for Jupiter, the Galilean Moons, the Sun, and the Earth.

Power Data

The Power Data Control panel provides a plot of the power generated by the solar arrays for the time window defined by the PTR. More concretely it displays the power generated with the attitude from the PTR and also the power generated by the attitude from the reference SPICE CK file from the meta-kernel in use by the chosen trajectory and assuming that the solar arrays are in a power-optimised orientation.

The Power Data is useful to assess the impact of the PTR with respect to the power available with the “default” attitude.

The data is the same provided by the Power Profile downloadable file.

Scene Items

This menu provides a list of options for the elements to be displayed in the display scene. These options are described hereunder:

• Fields of View: The FOV of a limited set of instruments as taken from the definitions from the corresponding SPICE Instrument Kernels. Each FOV has a different colour and can be activated or deactivated (all are activated by default).

• Main Bodies: Displays a number of elements to be visualized for Jupiter and the Galilean Moons: latitude and longitude grids and the Jupiter Rings Model.

• Minor Bodies: Provides the option to display and label the position of the inner and irregular moons of Jupiter. When clicking on it a context menu with all the available bodies is displayed and an autocomplete feature is provided. The available minor bodies are listed on the latest version of the SPICE JUICE Science Frames Kernel.

• Stars: Allows to search for a star with its HD ID and visualize it and assists the generation of an inertial PTR snippet with the latitude and longitude of the selected star in the EME2000 reference frame by clicking the Green Inertial button (which takes you to the Planning Timeline Request File panel) and displays the ViZier [CIT05] star information with the blue button. Multiple stars can be selected and are added with a list underneath the Stars Left Menu panel.

• Directions: Allows to display different directions or vectors as defined in the AGM Definitions file.

• Dynamic Frames: To display a number of dynamic frames that are calculated on the fly. Currently the JUICE Ramming direction pointing (RAM) frames for Jupiter, Callisto, Europa, and Ganymede are available. These directions can only be seen from the Spacecraft View Display.

Note

RAM pointing stands for a pointing whose primary axis is the velocity direction; the RAM side of the S/C is the side that points in the direction of the satellite’s motion. It is called the RAM side because it is the side impacting/ramming into the fluid that the satellite moves through -such as the ionosphere-.

Jupiter Rings Model

PT includes a Jupiter Rings model activated by default. The rings are defined as follows:

Name	Color	Internal radii (km)	External radii (km)	Thickness (km)
Halo Ring	Red (#ff0000)	10000	122400	10000
Main Ring	Green (#00ff00)	122400	129100	100
Amalthea Gossamer Ring	Blue (#0000ff)	129100	181350	2600
Thebe Gossamer Ring	Magenta (#ff00ff)	181350	221900	8800
Thebe Extension	Orange (#e7ad79)	221900	226000	8800

The rings are modeled as hollow cylinders (the cross section is rectangular) with a given thickness.

Please note that these rings are equivalent to the ones available via the Cosmographia Plugin and to the ones available in the SPICE-Enhanced Cosmographia configuration files available from the SPICE Kernel data set, with the main difference that the latter are modeled with the actual ring model thickness.

For more information on how the Jupiter Rings are modelled within the SOC please refer to Science Models.

Help

The Help Left Menu button resets the display scene to the Welcoming Display of PT.

Display Scene

The Display Scene is the core functionality of PT and allows to visualize in a 3D environment the geometry of an attitude profile.

The display scene has different visualization options as described in Views and is also used to display the different available attitude editors described in Scene Request.

Welcoming Display

The display home configuration provides information about the PT version, the version of its components: OSVE and AGM/EPS, the Release Notes of the PT. Finally it also provides a contact email to report bugs or suggestions to the JUICE SOC.

Please note that although it might seem that older versions of PT are eligible by clicking at them, doing so simply resets PT.

Note

The first time you access PT the following message will be displayed::

Communication Windows Disabled! The default attitude during communication windows are not taken into account. The default attitude during flybys include pushbroom manoeuvres for a 2 hour period around closest approach.

This message can be disabled.

Pointing View Display

The Pointing View provides a display viewpoint from the SC +Z axis co-aligned with the theoretical boresight of most of the instruments that allows to also visualize the instruments FOVs. The display has different controls for the PTR timeline, the camera position, and some visualization settings.

On the top-left, a timeline bar that shows where we are within the time window that is available in the PB buffer (most likely the entire PTR is not loaded) defined by the attitude profile is defined along with a repeat icon that takes us back to the window start and a play button that allows us to play/pause the simulation. We can also define the time within the window that we want to jump to; if a time outside the 2 hour window (which is a predefined quantity) is provided an error message is displayed.

Note

Clicking on the progress bar freezes the scene at that instant. Keyboard short-cuts:

• s Stops the timeline.

• p Start/resumes the timeline.

• r Rewinds one step.

• f Forwards one step.

On the top-right we can see the current time of the scenario in UTC Zulu format.

On the bottom-left we can pan along or across the viewpoint (always parallel to the view) a step in degrees that can be changed. The central icon resets the view and on the right we can see the current along/across offset.

On the bottom-center there is a timeline bar that displays the different PTR blocks either as green blocks for the observations or yellow blocks for the slews and that allows you to jump from one block to the other by clicking on it. The red dot indicates where in the timeline your simulation is at. You can zoom in/out the timeline with the mouse middle wheel and if you hover over a block you will see some metadata extracted from the block displayed. More concretely you will be able to see the OBS_ID, OBS_NAME or PRIME attributes from the PTR block comments. This timeline is very convenient to jump across the timeline and to understand where in the simulation we are.

On the center-right we have a number of visualization options. From top to bottom:

• Zoom in button

• Zoom out button

• Reset view button: Will reset to have all the FOVs in the display so it is not a “real” reset.

• Sun button: Will increase the brightness of the scenario in the display.

• Moon botton; Will decrease the brightness of the scenario in the display.

On the bottom-right the Camera Aperture (based on the Zoom) is provided in degrees. This quantity can be useful to assess the view of FOVs which are not defined within PT or to estimate offsets for pointings.

Spacecraft View Display

Provides display viewpoint centered in the SC from which we can see the SC model and that allows us to rotate and zoom around the SC center facilitating the interpretation of the context geometry.

The controls are very similar to the ones for the Pointing View Display except that the zooming and panning controls are not available (bottom-left and center-right) and instead the equivalent 3D controls of rotating around and zooming in and out are performed with the mouse by clicking and dragging to rotate and pressing the middle button and dragging for the zoom in and out.

An additional button on the center-right is available to flip the view along the SC +Z axis to compensate for some limitations of the display controls.

Working with PT

When PT is started the Welcoming Display scene is shown and you need to choose a JUICE trajectory for the simulation.

After having done so you need to define a PTR or an Attitude Timeline to be able to visualize the simulation display. If you are simply trying to visualize the contextual geometry and you are not really interested to a specific attitude you can start with the Default Attitude from the Scene Request menu. This will allow you to display the context geometry with a power-optimized Jupiter track pointing for a given date.

Of course the most interesting feature is to create your own or load a PTR or a PTR snippet using all the assistance provided by PT. Typically you will need to create or load PTRs during the Detailed Scenarios planning process when you are designing MAPPS timelines or maybe when you are designing PTR snippets for your Observation definitions.

By doing so, not only you will be able to visualize the attitude and do a quick assessment of what is seen by the FOV of your instrument of interest; you will also be able to check whether the PTR is syntactically correct, violates any constraint (modelled in the PT) and you will also be able to calculate the optimal slews in between different PTR snippets.

Finally a very powerful feature of PT, thanks to OSVE, is the possibility to export the SPICE Camera-Matrix kernel or the Resolved PTR from the input PTR.

The Resolved PTR

The resolved PTR is an XML PTR that replicates the PTR that you provided as an input but that calculates the start and end times and the slew blocks for these pointing snippets in which you have provided an open start or end time of the block. Typically, the resolved PTR is what the JUICE SOC uses to iterate the pointing design exercise from a detailed scenario.

PTR to CK, now what?

Having a CK file out of an attitude profile allows you to load the attitude information for many different applications. To provide a simple example, you can visualize the attitude profile with the SPICE-Enhanced Cosmographia Tool, or you can use the Planetary Coverage Package to assess the changes in coverage for different attitude profiles or to load the CK with your own SPICE based application and most important of all to share it with your colleagues and community.

This said you need to be cautious and aware that in order for the generated CK to be valid outside of the PT simulation, you need to ensure that you use the same rest of SPICE Kernels ideally as defined by the meta-kernel used by PT with the selected trajectory. This information is available at the rightmost button of the top level horizontal bar: JUICE, e.g.:

     JUICE - Pointing Tool
Start Coverage: 2031-01-19T19:14
End Coverage: 2035-09-29T00:00
Metakernel: juice_crema_5_0b23_1_v320
SKD version: v320_20220725_001

This particular meta-kernel (MK) can be obtained from the JUICE SPICE Kernel data set from BitBucket or via FTP.

When using SPICE with these kernels, ensure that the CK is loaded after the MK or after loading the individual kernels of the MK.

Pointing Tool/AGM REST-API

The Pointing Tool has a REST-API interface that allows you to submit a PTR in order to validate the PTR and to obtain a SPICE Camera-Matrix Kernel (CK) or the quaternions resulting of the PTR in the same way that you would do with the Graphical User Interface of the web tool.

This is a very convenient interface for pointing design. The REST-API entry point is:

https://juicept.esac.esa.int/agm

In order to facilitate the work of pointing design and to interface the REST-API we highly recommend you to use the esa-ptr Python package.

A working example on how to use the Pointing Tool REST-API and the esa-ptr package is provided in the following Python notebook.

Available Trajectories

In order to sort the available trajectories for the REST-API use the following end point to get the mapping between “trajectories” and the context that is used to resolve the queries related:

https://juicept.esac.esa.int/assets/trajectory_contexts.json
[
  { "name" : "JUICE CREMA 3.0", "context": "30"},
  { "name" : "JUICE CREMA 3.1", "context": "31"},
  { "name" : "JUICE CREMA 3.2", "context": "32"},
  { "name" : "JUICE CREMA 5.0 Cruise", "context": "50c"},
  { "name" : "JUICE CREMA 5.0", "context": "50"},
  { "name" : "JUICE CREMA 5.0b23_1 Cruise", "context": "50b23_1c"},
  { "name" : "JUICE CREMA 5.0b23_1", "context": "50b23_1"},
  { "name" : "JUICE CREMA 5.1 150lb_23_1 Cruise", "context": "51c"},
  { "name" : "JUICE CREMA 5.1 150lb_23_1", "context": "51"}
]

In addition The next URL https://juicept.esac.esa.int/<context_id>/serviceinfo allows you to access to the details of the configuration, including the meta-kernel to be used for the AGM calls. E.g. For the trajectory JUICE CREMA 5.1 150lb_23_1, we would use the context 51:

https://juicept.esac.esa.int/51/serviceinfo
{
    "coverage_start": "2031-01-19T19:14",
    "coverage_end": "2035-09-29T00:00",
    "sample_date": "2032-07-02T16:22",
    "metakernel": "juice_crema_5_1_150lb_23_1_v420",
    "skd_version": "v420_20221220_001",
    "trajectory": "Crema 5.1 150lb_23_1",
    "mission": "JUICE",
}

AGM Definitions

The AGM definitions are provided in configuration files used by the AMG instance through OSVE for the Pointing Tool and provide

There are three types of definitions:

• Directions (dirVector): Define a direction/vector with respect to a given reference frame. E.g.: +X axis of the JUICE Spacecraft Reference frame or the RPWI antenna wrt the JUICE Spacecraft Reference frame. These directions can be defined with an origin and a target, assuming that these bodies are defined within AGM or by specifying a X, Y, Z direction wrt to a given frame. Directions are defined in JUICE MULTIBODY FIXED DEFINITIONS.

• Surfaces (surface): Define a natural body of the solar system. Jupiter, Callisto, Europa, and Ganymede are defined. The body have an ellipsoid model and are defined wrt to a reference frame. Surfaces are defined in JUICE MULTIBODY FIXED DEFINITIONS.

• Blocks (block): Pointing Blocks are predefined pointing blocks that assist the generation of the pointing timeline and are used by the auto-fill functionality of PT. They can also be used as a reference. Blocks are defined in JUICE MULTIBODY PREDEFINED BLOCKS.

• Event Definitions (eventDefinition): Define geometrical events to apply constraints and checks that will be c calculated by AGM. For example a S/C +X Panel illumination event might trigger an illumination violation constraint if an illumination minimum an maximum value are provided. Event Definitions are defined in JUICE MULTIBODY EVENT DEFINITIONS.

The Definitions section of the info button of the top horizontal bar allows you to display all these definitions, sort them by Name and Description and filter them.