Functional anatomy of BRAHMS

(1) User calls front-end, which is a lightweight wrapper for Engine. (2) Engine loads System from System File, and may liaise with Engines in other Voices. (3) Engine calls Process, Data and Utility Components through their Events Interfaces, and moves Data Components around.
(4) Process Components call Data Components (to access their content) through their Events Interfaces.
(5) Process (and Data) Components may additionally call Utility Components through their Events Interfaces.

Anatomy

Engine
The bulk of BRAHMS. Responsible for instantiating processes and passing them their initialisation parameters, connecting them together, then leading them all together along the simulation timeline, passing data objects amongst them as required, and ensuring that they remain in step. Can run in two modes: "Solo" runs in a single shared-memory space and takes advantage of multiple processors using multi-threading; "Concerto" runs across multiple shared-memory spaces (see Voice 2 in Figure, right), leveraging multiple processors in each space using multi-threading, and leveraging multiple spaces by inter-process communications (over TCP/IP or MPI).
Component Interface
The interface offered to Components by the Engine. New Components and new Engines may be developed, but this interface will remain unchanged (or, at least, backwards-compatible). Revisions to this interface that would require recompiling (and/or modifying) existing Components will be avoided.
Client Interface
The interface offered to clients by the Engine. Currently, the only client that uses the BRAHMS Engine is the lightweight brahms-execute wrapper, providing the functionality of the Engine from the OS shell. However, any front-end can use the Engine - for example, this is one way that a BRAHMS execution can be integrated into a broader execution environment.
Process
(Component) The computation engines that take zero or more inputs and generate zero or more outputs. Examples would be std/math/esum which adds its numeric inputs and generates a single numeric output, and std/source/spikes which takes no inputs but generates one spikes output.
Data
(Component) The data containers that are passed between processes. Examples are std/data/numeric which contains an N-dimensional array of numeric primitives, and std/data/spikes which contains a list of streams which are in a spiking (logic high) state.
Utility
(Component) Additional components that provide library functionality (e.g. computation services) within the SystemML framework. That is, they are dynamically linked libraries, but they are subject to version tracking in the same way as any SystemML component. An example is std/util/rng which implements random number generators.
Component Bindings
Component Bindings offer an interface that non-native Processes can use to plug into a BRAHMS execution. For instance, 1258 and 1262 are the current Component Bindings for the Matlab (.m) and Python (.py) languages.

A Wider Context

Here, we see the whole BRAHMS/SystemML software suite as it fits together into an integrated system. First, there is BRAHMS itself; this is the large green part to the right, and is driven by two XML files. Second, the Matlab Bindings for BRAHMS and SystemML provide read/write access to the Execution File and the System File (SystemML), and (optionally) can invoke BRAHMS to perform an execution. Lastly, the SystemML Cache Manager which updates the local cache from the SystemML Server; however, the Cache Manager is not yet implemented, so only locally stored Namespaces are currently used.

 Green parts are part of the BRAHMS software project.

 Blue parts are part of the SystemML software project.

 Red is user software that BRAHMS uses (Components).

 Purple is third-party software (Matlab, here).

 Yellow is user software that uses BRAHMS.

Currently, green and blue (BRAHMS and SystemML Toolbox) are packaged together in the all-in BRAHMS releases.