Skip to main content
jBEAM Logo

jBEAM Architecture

jBEAM is based on a clear component architecture and can be used in different environments.


jBEAM runs on multiple operating systems.

The software jBEAM is object oriented designed and consists of a producer - consumer structure. The user information is stored in a data item, events inform consumers regarding status changes.

You have a file with measurement data. In this example, a data file in diadem format. In jBEAM you create a new instance of the class diadem import. This class contains all the information, how a diadem file is read, in addition all information, how to produce data items in jBEAM. The diadem importer generates in this example 2 data items of type double channel, channels in floating point format. Thus the importer is a producer who "produces" data items.

As an example for a data consumer, a graphic object of type universal 2D graph is created. In the graph a chart of type "XY graph" is defined, whose input is now data item 1. Now the measured values ​​from the diadem file are shown automatically as curve. The second data item can be shown in a second diagram of the type "XY curve" in the same graph, or a second graph is defined and the measured values are shown as diagram of type XY-curve in this second graph.

Example: File-Import

Automatic update

If now the existing instance of the diadem importer is modified, a dialog box opens with parameters for import. One parameter is the file itself. If a different diadem file is chosen and confirmed, the following process runs down:

  1. The content of the new file is loaded and stored in data items. If channel name or type fit, the existing ones will be filled with new data.
  2. The data items inform per event all its consumers (in this case the graphic objects) about the fact that the content has changed.
  3. It is now up to the consumer to react to this information. In this case, the graphics provoke redrawing.

Therefore the user can always be sure, that the current visible status in jBEAM is correct, without retrieving any auto sequence.

Branches and calculations

jBEAM Architecture File-Import with Calculation
File-Import with Calculation

Now, if the read measurement channel is converted with a formula or if a FFT analysis should be made, an instance of the class "Formula Editor" is defined. The formula itself is one of the parameters of the instance and can be entered in the editor.

This calculation is now both, consumer as well as producer. It consumes the "Data Item 1" and produces the "Data Item 3". The automatic update works also in this case when the output file is changed:

  1. The content of the new file is loaded and stored in data item 1 and 2. If channel name or type fit the existing ones will be filled with new data.
  2. The data items inform per event all its consumers (both the calculation as well as the graphic objects) about the fact that the content has changed.
  3. The calculation knows now that the input data has changed, and executes the calculation with the new data. The data item 3 is now informing its components, in this case XY graph 1.
  4. It is now up to the consumers to react to this information. In this case, the graphics provoke redrawing.

External CEA components

jBEAM is an ASAM-CEA compatible framework that can be extended with external plug-in components correspondent to the ASAM-CEA standard.

These external ASAM-CEA components work in jBEAM as if they were internal jBEAM components. Due to the fact that they are compiled, the processing speed is maximum.

External ASAM-CEA Component in jBEAM
External ASAM-CEA Component in jBEAM

Object-Architecture: Classes - Instances

The object oriented software jBEAM allows intuitive operation. Nevertheless, there is a pitfall into which users consistently blunder who do not know the correlation between classes and instances.

Referred to IT Technology, each importer, each calculation, each graph corresponds to a class. This class includes all the logics, that are important for these components. Create via the menu e.g. a new calculation, an instance of this class is formed. This instance contains now parameters that can be different in each instance. For example five formula editors can be created. These are five different instances of the same class. Each of these five different formula editors can have different formulas or different input channels, which are stored in the different instances.

If the user goes in the menu to the formula editor, a new instance is created. In the dialog that opens automatically, the instance can be parameterized. If the user wants to modify this already defined formula editor again, he retrieve the list of existing instances under "Modify". When he returns to the menu item "Formula Editor", a new formula editor (new instance) is created again, and the user is surprised that the parameterization dialog is in the initial setting, and all of his entries are gone.

Thus, if an existing component must be changed, you have to go to the list of existing instances under "Modify".