NeurOS Integration Points
NeurOS is specifically architected to easily integrate external technologies, both to enrich NeurOS applications, and to use/embed NeurOS applications with other systems. A NeurOS application designer can use the best available technologies in cognitive systems without sacrificing the generality and broad capabilities of other NeurOS modules.
Integration points include the following:
Integrated external functions and systems must follow general NeurOS module rules, to ensure system and application stability, portability, scalability and distributability. They may not block, take a long time to compute, nor respond to non-NeurOS-managed external events or timers. Thanks to NeurOS virtual time, variations in real processing time generally have no affect on overall system correct operation.
Functions
All NeurOS modules have parameters. Most parameter values can be set to expressions which can invoke (Python-callable) external functions. In particular, the built-in Transformer, Filter and Group Operations modules have such expressions as part of specifying their processing details. For example, Python matrix manipulation and mathematical functions are made available in this way. It is only necessary to specify a Python module import specification to the properties of a neural graph to make functions available. Functions/libraries in other languages (e.g., C/C++) can be included by creating a Python wrapper for them. In addition to not blocking nor taking too long to execute, functions embedded this way must not expect to share any process-specific resources with other module instances: memory, locks, timers, file or device handles.
Wrapper Module
The Wrapper module enables interfacing with external systems via a variety of common external interprocess communication interfaces: pipes, streams, sockets, REST-ful interfaces, etc. Parameters control data formats, parsing, synchronization, etc. The wrapped interfaces must follow general module constraints: they cannot block nor take a long time to process.
Sub-graph Module
Although not a vehicle to directly integrate external capabilities, the Sub-graph module can be used in concert with other integration mechanisms to create custom modules which embed external functions. For example, one can use built-in NeurOS modules to pre- and post-process signals to and from wrapped or custom modules, and capture the whole sub-assembly as one reusable module.
Further, it is good design practice to build needed functionality first with available NeurOS modules as a sub-graph module. Later, as experience and application needs call for a more custom implementation or an external technology, uses of this sub-graph module can be transparently replaced with a more custom module.
Input and Output Modules
Several built-in modules allow direct interfacing to files, pipes, streams and sockets, with parameters for data formats and synchronization. This allows loosely-coupled interaction with other concurrently running systems.
Custom Modules
Writing a custom module to work with NeurOS is easier than it sounds. A custom module is a sub-class of a general Module class, which takes care of a great many details. The built-in Custom module provides an easily-used template that takes care of most of the details.
The only required function to implement is run(). This function is called by the NeurOS run-time system at each moment in virtual time when there is at least one input event, or a NeurOS-provided self-timer expires (for polling and time-decay based functions). The run() function uses NeurOS-provided accessor functions to access input neural signal events in various useful ways, to create and send output events, and to access current parameter values. Internally it may use any programming language features including local and static variables, but may only read-share class-level variables, even multi-threading and multi-processing, subject to the NeurOS rules. If long computation is sometimes needed, this should be performed in other threads or processes with non-blocking synchronization. It should catch its own exceptions.
Other (optional) parts of a custom module include:
- module details: name, module group (for NeurOS Designer parts bin placement), icon
- custom parameters: these can include a variety of user interface widgets for supplying numbers, strings, select-lists, sliders, buttons and check boxes, edit boxes, file boxes (e.g., for initialization files) and expressions
- a validate() function called when parameter values are changed and prior to application running, to ensure self-consistent parameter settings
- a start() function called when a NeurOS application begins running, to initialize any external resources (e.g., open files, device connections, database connections, interprocess communication interfaces) and internal module state
- a finish() function called when a NeurOS application is shut down, to cleanly shut down and release external resources