-
Notifications
You must be signed in to change notification settings - Fork 1
Module Capabilities & Configuration
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.
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:
- The data model needs to provide sufficient flexibility and modularity to not unnecessarily restrict module development.
- The data need to be provided in a standard machine-readable format so that system behavior is well-defined and predictable.
- 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.
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.
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.
Modules also need to publish what data/messages they publish & subscribe.
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.
- 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
- Module Manager monitors module status topic