Skip to main content
Jump to: navigation, search


< Apogy
Revision as of 12:40, 28 August 2018 by (Talk | contribs) (Created page with "= Apogy User's Guide = == Table Of Contents == __TOC__ == Introduction == Apogy was originally developed at the Canadian Space Agency to control space exploration rovers and...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Apogy User's Guide

Table Of Contents


Apogy was originally developed at the Canadian Space Agency to control space exploration rovers and their associated sensors. Integrating all these systems developed by many different contractors and allowing them to be controlled as an integrated entity represented a challenge. In order works, a tool to plan, validate, execute and monitor integrated operations to support multiple missions was required. The technical team soon realized that a reusable framework could save a lot of work and allow for future growth. Apogy is the result of this thinking.

Apogy was built to:

  1. Be an organizationally neutral core framework (we did not want to be locked in with any particular contractor proprietary tool);
  2. Maximizes reuse between missions (keep the work to the specifics of each mission);

In order to so, Apogy :

  1. Is a component-based architecture that allows systems (ex: instruments, rovers, satellites) to “plug-in” and allow the system developer to concentrate on their system specific needs and the tooling to use them.
  2. Makes use of Open Source librairies that are Eclipse Public License compatible;


In Apogy, users control Systems by invoking commands (through Programs) and monitor the System's health through telemetry (i.e. states).

These Systems are operated in a Environment which defines such things as Digital Elevation Maps, orbit models, sun position, etc (i.e. what the Environment contains).

User, System, Environment and Data Product.

The System's command produces result (i.e. returned value, such as an Image, an error code, etc.) that Apogy geo and time tags. This allows the results to be displayed within the 3D Environment. This helps in maintaining the situational awareness of the operator and keep the data in context.

The following tables presents a brief summary of the Concept defined in Apogy. Please refer to the sub-sections for more details.


In Apogy, the Session is the entity that contains all the configuration and data that are required to make use of Systems. The session is implemented as an Eclipse Project with an Apogy nature, and as such, is mapped to the host file system. Sessions can be exported/imported to and from archived files (.zip).

The Session project includes a central resource (session.sym) that contains most of the configuration elements (Variable, Context, InitialCondition, etc) and also has referecens to other ressources contained in the project (scripts, data products, etc). In Apogy there is at most one active Session at any given time.

The Session contains:

  1. the Environment being used;
  2. the list of Programs that can be executed;
  3. the list of available InitialConditions;
  4. the list of Tools that are available.


In Apogy, a System is an entity that can execute commands and provide its state information. Typically Systems represent actual hardware (ex: a rover, a camera, a robotic arm) but can be used to represent something more abstract (a planning system, a resource dispatcher, etc.).

In Apogy, a user makes use of the Systems to perform tasks in a given Environment. The System supports commands and reports on it status through its telemetry : the System is defined by its interfaces. Given this definition, a System can be modeled as a class : methods represent commands (with their parameters and return value) and the attributes represent states returned as part of telemetry. In Apogy, a System is defined using the Eclipse Modeling Framework.

In Apogy a System is named and is defined in EMF model. This model includes:

  1. The System Interface Class defining the commands and attributes it supports;
  2. A list of Connection Points where other sub-system can be attached;
  3. A list of Assembly Links that are used to assemble a System's sub-System (in composite Systems);
  4. A topology of nodes that are used to defined the system representation in 3D;
  5. A list of Topology Bindings that are used to bind attributes of the interface class to behavior in the topology (ex: binding the value of a 3D transform to the value of a revolute joint position);

Simple Systems can be assembled together to create composites Systems (ex: Integrated Rover Example). This allows sub-systems to be modeled independently and reused as part of different assemblies. The assemblies of Systems is supported through System Type Members, Connection Points and Assembly Links.

System Interface Class

The System's Interface Class refers to the EClass that defined the methods and attributes of the System. Only methods and attributes defined in the interface can be accessed by Apogy to create commands, display values, bind attributes, etc.

System Type Members

Composite System contains Type Members that refers to other System. This is the pattern used by Apogy to implement composite data type (ex: struct in C programming language ). These Type Members can be made accessible to the parent System.

An example of a composite System and its Type Members. For example, type member platform is of type MobilePlatform.

Apogy allows operations to be called on a composite System's Type Member (ex: calling rover→mobilePlateform.moveForward(1.25)) in a hierarchical fashion. In the same way, attributes of sub-system can be accessed (rover→mobilePlateform.leftWheelPosition).

System can be compose at multiple levels (i.e. a System can have type members that are themselves composites Systems and so on.). The Integrated Rover is an example of such a System.

Connection Points

Connection Points define physical locations where other sys-system are expected to be connected. To used the analogy of a construction toy's blocks, connections point points define the brick studs.

A System connection points and relationship to the System's topology. connection points (yellow rectangles) and topology Nodes (blue rounded rectangles).

They are named and refer to a Node defined in the System's topology. The root connection point is implicit and always refer to the System's root topology node.

Assembly Links

Assembly Links describe how systems are attached to each other in composite Systems.

A composite system assembly using connection points (yellow rectangles) and assembly links (black arrows). The IntegratedRoboticArm sub-system is attached to the Front Connection Point located on the MobilePlateform, while the Camera1 sub-system is connected to the Top connection point.

In the construction toy's analogy, the assembly links represent a construction set's instructions. The assembly links are named and refers to their parent's connection point to which the subsystem root connection point is attached.


A user can define multiple instances for a given System (ex: vehicle1 and vehicle2 of type MobilePlateformApogySystem). Similar to the way multiple variables of a given type can be defined in programming languages, Apogy uses the concept of Variable.

Each Variable has a name (that should be unique) and refers to the type of System it represents. Variable can refer to simple or complex System.


When developing complex operations sequence or testing scripts that command Systems to perform tasks, a user often needs to run such commands on some sort of simulated version of the Systems.

In other cases, during development, a specific sub-system of a larger assembly may not yet have an implementation that communicates with it's hardware (or the hardware may not yet be available). A way for the user to work on operational sequence or scripts should be made available.

In order to addresses such cases, Apogy makes use of Context. At it's base, a Context maps Variable to actual implementations of the Interface Class of its System and sub-systems. By doing so, when a Variable is instanciated, the actual Interface Class Implementation specified in the Context is used. Used together with a System Interface sub-classes, the Context allows commands and script to be executed in a transparent fashion in diverse implementation settings.

Simulated Context active. Real Context active.
Simulated Context selected as the active context. Real Context selected as the active context.

In the example above, 3 Variable have been defined:

  1. myRover : Refers to a System which Interface Class is Rover, which has 2 sub-classes:
    1. RoverSimulated : A simulated implementation of the Rover;
    2. RoverReal : An implementation that connects to the actual hardware rover.
  2. myArm : Refers to a System which Interface Class is Arm, which has 2 sub-classes:
    1. ArmSimulated : A simulated implementation of the Arm;
    2. ArmReal : An implementation that connects to the actual hardware robot.
  3. myLidar : Refers to a System which Interface Class is Lidar. In this cas, the Lidar hardware being no yet completed, only 1 sub-class is available:
    1. LidarSimulated : A simulated implementation of the Lidar;

The user has created 2 Context : Simulated and Real. In this case, both real and simulated version of the rover and arm are used, but the Lidar hardware not being available, both Context make use of the simulated implementation (LidarSimulated) of the Lidar. This setup allows command sequence or scripts to be developed and tested now using the Simulated context, and later used with the real world implementation when the actual Systems become available.

While many Context can be defined in a given Session, only one can be selected as the active context. The Context definition includes:

  1. A name (should be unique);
  2. The DataSet where results will be stored. This allows result from different Context to be saved separately (this is often useful to keep data from a simulated run separate from data produced by actual, real System).


The Environment contains the following:

  1. the Variables in use
  2. the list of available Contexts and the one currently active;
  3. the list of available Worksite and the one currently active;
  4. the list of available Time Source and the one currently active;

Contains the definitions of worksite, time sources and Systems;

Defines what the user has to work with in a specific mission such as the System instances.

  1. Contains the definitions of the Worksite, Time Sources and the registered Apogy Systems;
  2. Defines what you have to work with in a specific deployment;

Time Source

Time Sources are used to feed the time to the Session. This in turns updates the position of the sky elements (Sun, Moon, Stars).

The Time Sources element contains the available Time Source, only one is set as the Session Active Time Source.

Type Description
Fixed Time Source A time source representing a fixed date and time.
Current Time Source A time source that represent the current time, updated a regular interval.
Selection based Time Source A time source that updates its time upon selection of any Timed element in the UI.
Browseable Time Source A time source that can browsed, reset, play forward or reverse and accelerated.


A Worksite represent the physical environment where the Systems are being used. While many Worksite can be defined in a given Environment

  1. Defines the area that the System are operating in for the particular mission;
  2. Include a priori information about the area (e.g. Digital Elevation Maps (DEMs), orbital imagery, etc.);



Back to the top