Module Capabilities & Configuration

Background

Modules will offer a wide variety of functionality, often with a complex set of inputs and outputs. Module functionality, along with the corresponding inputs and outputs needs to be consistently categorized and documented. The structure of this data has three main design criteria:

1. The data model needs to provide sufficient flexibility and modularity to not unnecessarily restrict module development.
2. The data need to be provided in a standard machine-readable format so that system behavior is well-defined and predictable.
3. The functionality of a module must be presented in such a way as to be accessible to educators and clinicians, so they can readily understand what a given module does, and whether it will be able to meet their educational goals.

Capabilities

Module functionality, inputs, and outputs are broken down into logical units called Capabilities. Modules will always have at least one Capability, and most modules will have multiple Capabilities. Each Capability of a module corresponds to some piece of functionality the module provides, and is designated by a short word or phrase such as 'Pulse', 'IV Infusion', or 'Battery'. Each Capability will have one or more Inputs or Outputs, and all Input and Output configuration for a module must be grouped into Capabilities.

Capabilities are specified by a Scenario to determine what functionality is required to simulate that Scenario. This enables Scenarios to be created and shared independently of modules. Additionally, module Configuration data is specified per Capability. Thus, Capabilities that are not used by a Scenario can be disabled to reduce resource consumption. Finally, modules report their status on a per Capability basis. This allows for the system to programmatically determine if the Scenario is ready to run and provides for more granular error reporting.

Operational Schema

Each module must outline its functionality, inputs & outputs, and configuration parameters, grouped by Capability, in a document called an Operational Schema. The Operational Schema will have a fixed machine-readable format, which is currently in development. Each Capability in the Operational Schema will have a name & description along with inputs, but 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.

Published & Subscribed Data

Modules also need to publish what data/messages they publish & subscribe.

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.