Enum PntosPluginTypes

Enum Documentation

enum PntosPluginTypes

An enumeration of the types of plugins supported by pntOS for this loader API version. Each enum entry maps to a corresponding structure with PascalCase naming. For example, the PNTOS_CONTROLLER_PLUGIN value in this enum is indicating a plugin represented by the struct PntosControllerPlugin. Note that because the utility plugin has no additional API requirements beyond the PntosCommonPlugin, there is not a PntosUtilityPlugin. Instead, implementers of PNTOS_UTILITY_PLUGIN should implement and return a PntosCommonPlugin.

Values:

enumerator PNTOS_UNDEFINED_PLUGIN

A unused entry, designed to allow code to detect accidentally unset fields. This value must not be used by any plugin implementation, other than to check for an erroneous default value being used.

enumerator PNTOS_CONTROLLER_PLUGIN

The primary plugin that controls the entire operation of pntOS. After the pntOS loader collects the set of plugins available, execution passes to the controller plugin. At that point, the controller is responsible for deciding how it should use, when it should use, and if it should use the other plugins, including routing communications between them and controlling the concurrency model used.

The controller plugin is designed to work together with the platform integration plugin (PIP) to control overall behavior of the system. In particular, the controller consists of re-useable logic that is not specific to a particular solution, whereas the PIP consists of platform-specific logic. The primary job of the controller plugin is to place each plugin into a concurrency primitive (thread, process, etc.) and then manage the communications between those plugins via the mediator the controller provides. The controller may also configure a single threaded approach if desired.

Any logic which is specific to a particular solution, platform, or vehicle should be placed in the platform integration plugin instead of the controller. After the controller is done initially setting up the concurrency model, it should hand control to the PIP, to handle command and control of the plugins outside the scope of inter-plugin communications and message routing between plugins.

enumerator PNTOS_FUSION_PLUGIN

A plugin that models an information fusion approach. This plugin accepts modular representations of state space models, sensor descriptions, raw measurements, and computational filtering engines, all provided by external sources. It then performs the bookkeeping needed to hook these modules up to each other in a extensible and flexible way. State space models and sensor descriptions are provided by state modeling plugins, raw measurements are provided by transport plugins, and filtering engines are provided by fusion strategy plugins.

enumerator PNTOS_FUSION_STRATEGY_PLUGIN

A low level computational engine that can perform sensor fusion given pre-determined fixed models of errors and raw measurements. Because this plugin requires fixed models, another plugin is required to orchestrate modular descriptions of the fusion problem into a fixed-size problem. The fusion plugin is used to orchestrate modular descriptions into a fixed-size problem suitable for the computational engine in this plugin to consume.

enumerator PNTOS_PLATFORM_INTEGRATION_PLUGIN

An output plugin for pntOS to interact with the platform it is running on. While pntOS uses a uniform set of conventions internally (e.g. ASPN messages), pntOS is often used on legacy platforms that are non-cooperative and impose requirements on the input/output expected of pntOS. For example, analog time outputs or PVA messages at a certain rate and non-ASPN format might be required by a vehicle that pntOS is running on. The platform integration plugin converts pntOS internal messages into whatever external outputs may be needed on the current platform. It is designed to be the piece of NRE that must be rewritten when using pntOS on a novel platform.

UNSTABLE: This feature is unstable and is not yet considered part of the stable pntOS API. Usage of this feature is highly discouraged in non-experimental code, and its definition may change at any time.

enumerator PNTOS_INITIALIZATION_PLUGIN

A plugin that provides initialization algorithms. In general, this plugin must be able to consume some set of measurements and produce an initial solution for the navigation system. This plugin encompasses everything from a traditional gyrocompass to a cold-start dynamic positioning.

UNSTABLE: This feature is unstable and is not yet considered part of the stable pntOS API. Usage of this feature is highly discouraged in non-experimental code, and its definition may change at any time.

enumerator PNTOS_DATABASE_PLUGIN

A plugin for storing generic datasets that might be consumed by many plugins. For example, DTED elevation data may be used by many different plugins. Thus, a user might write a database plugin that encapsulated tiles of elevation data which is available for query by any other plugin.

UNSTABLE: This feature is unstable and is not yet considered part of the stable pntOS API. Usage of this feature is highly discouraged in non-experimental code, and its definition may change at any time.

enumerator PNTOS_TRANSPORT_PLUGIN

A plugin that listens for incoming sensor/other data on a network bus and provides this data to pntOS. pntOS has an internally consistent messaging structure which may not match the messages transmitted over the wire to pntOS. Thus, one of the transport plugin’s primary roles is to convert arbitrarily formatted data off the wire into the internal pntOS ASPN representation. For network buses that already transmit ASPN data, the transport plugin may end up being a trivial plugin, simply marshalling data off of a network connection into the system.

enumerator PNTOS_UI_PLUGIN

A plugin for enabling user interfaces to be hooked up to pntOS. This plugin is designed to enable displays to users to both see the current state of pntOS and also configure/tweak it. Note that it is not designed for hooking up operational displays, but rather debugging / developer consoles. For outputs that will be sent to operational live displays on the platform, the platform integration plugin is preferred.

enumerator PNTOS_ORCHESTRATION_PLUGIN

A plugin that implements the orchestration monitoring framework. In general, complementary navigation techniques incur a large risk of solution corruption if any one of the new sensors is misconfigured, mismodeled, miscalibrated, or otherwise failing. The orchestration plugin monitors all sensors in the system and generates different orchestration solutions depending on the user’s risk tolerance. Because there is a huge variety of orchestration approaches, the orchestration plugin is further modularized into orchestration strategy plugins, which implement a particular orchestration approach for a particular sensor or situation.

enumerator PNTOS_ORCHESTRATION_STRATEGY_PLUGIN

A fine-grained integrity plugin that itself plugins into the larger orchestration plugin. This plugin is designed to be implementable by a developer who is an expert on a particular sensor or phenomenology, without being an expert in the entire orchestration framework used by pntOS. A integrity algorithm specific to a single sensor or situation may be implemented in this plugin, and then injected into the larger orchestration which captures many orchestration strategy plugins for different sensors.

UNSTABLE: This feature is unstable and is not yet considered part of the stable pntOS API. Usage of this feature is highly discouraged in non-experimental code, and its definition may change at any time.

enumerator PNTOS_REGISTRY_PLUGIN

A registry of configuration and status data for pntOS that is available to all plugins. Registries allow for plugins to have side-channel information shared between plugins without pntOS being pre-aware of the data that needs to be transmitted. For example, support a plugin modeling a vision nav sensor has computed a camera calibration matrix. Simultaneously, a UI plugin would like to show the current calibration matrix to the user, and allow that user to modify the current matrix if the user desires. Because the vision nav sensor ordinarily would be modeled by a state modeling plugin and the user-facing UI implemented by a UI plugin, these two plugins would have no way to communicate current/updated values of this matrix. Via the registry, these plugins can decide by convention on a key-value that store the calibration matrix and enable high-speed bi-directional communications of the value of the calibration matrix in a thread-safe way.

The registry supports value observers for listeners to be notified when values are changed, monitoring/logging of when values are changed and by what source, and access control lists to guard certain keys.

enumerator PNTOS_INERTIAL_PLUGIN

A plugin that generates PVA solutions from an inertial.

UNSTABLE: This feature is unstable and is not yet considered part of the stable pntOS API. Usage of this feature is highly discouraged in non-experimental code, and its definition may change at any time.

enumerator PNTOS_STATE_MODELING_PLUGIN

A plugin that models the errors of the various sensors and systems that measuring the world. Abstractly, a state modeling plugin includes modular representations of (a) state space models (including nuisance parameters) and (b) state model providers and how measurements are related to the states in the state space. Due to there being several mathematical models of varying fidelity to describe sensors, each state modeling plugin must declare what model it is using to represent sensor errors. For the standard model, each state modeling plugin is a bundle of zero or more state blocks, zero or more measurement processors, and zero or more virtual state blocks.

enumerator PNTOS_LOGGING_PLUGIN

A plugin that logs system events to an arbitrary sink. A sink may be a file, a console, an attached GUI, a network destination, or any other destination of interest.

enumerator PNTOS_UTILITY_PLUGIN

A utility plugin performs implementation-specific functions that may require access to pntOS resources (such as the registry) via the PntosCommonPlugin API. Otherwise, this plugin has no other API-defined functionality.

enumerator PNTOS_PREPROCESSOR_PLUGIN

A plugin that processes data received from a transport before it is sent onward into other pntOS plugins. Intended use cases include:

  • fixing erroneous messages that do not conform to the ASPN data model, due to e.g. hardware malfunction

  • preprocessing ASPN measurements of one type into one or more alternative ASPN measurements, to make them suitable for processing by currently available measurement processors. For example, a raw image might be delivered to pntOS, and then converted into features such that a feature-processing measurement processor could utilize it.

UNSTABLE: This feature is unstable and is not yet considered part of the stable pntOS API. Usage of this feature is highly discouraged in non-experimental code, and its definition may change at any time.

enumerator PNTOS_NUM_PLUGIN_TYPES

The last entry in the enum, designed to allow users to know the number of plugin types defined. This value must not be used by any plugin implementation, other than to find the length of this enum.