Skip to content

Module Capabilities & Configuration

Jump to bottom
Benjamin Riggs edited this page Jun 6, 2017 · 19 revisions

Introduction

Modules will have a wide variety of functionality, often with a complex relationship of inputs, some optional, some required, and outputs. Inputs will usually include resources (data, power, fluids), configuration settings, and user actions. Resources (data, power, fluids) may also be outputs of a module, along with displays.

Additionally, modules will have high-level design goals that inform what their intended use is, such as 'simulate IV placement and drug administration in the right forearm.' These conceptual capabilities need to be accessible to people who create simulated scenarios so they can ensure they have the required components to perform the desired simulation.

Finally, all of the resource inputs & outputs, configuration options, and capability descriptions need to be presented and organized in a machine-readable format. This document is called a module's Operational Schema. The Operational Schema will allow scenario creation tools to verify the selected modules will be able to simulate the desired scenario, and set the configuration parameters of the selected modules appropriately.

Operational Schema

(name subject to change if somebody comes up with something better)

The module Operational Schema is broken up into sections called Capabilities. Each Capability will have an associated name & description. Capabilities will contain inputs, both required and optional, outputs, and configuration parameters. Capabilities may also have additional fields describing supported interventions as well as potential performance assessments.

For example, an IV arm with a pulse and a battery could have three distinct Capabilities: Simulating/evaluating IV placement & drug administration, a pulse as a Display, and a battery to power itself or the rest of a manikin. Each of these would have their own input & output requirements & configurations.

Implementation Notes

We're currently leaning heavily toward XML-based Operational Schema, with XML Schema defining the structure. The actual configuration settings for a module will also be defined in XML and delivered to modules via a standard configuration DDS Topic.

Runtime Configuration & Status

  • Status topic reports status enum (ready, initializing, error, etc.) & configuration
  • Module configuration is exposed via XML over DDS
  • Modules publish their current config
  • Module Configurator connects to system and publishes updates to module configs

Clone this wiki locally