jBEAM software architecture maximizes output and usability

Our jBEAM software features object-oriented design and a producer-consumer structure. User information is stored in a data item, and events notify consumers about status changes. jBEAM can also run on multiple operating systems.

Producer-consumer structure

jBEAM accesses measurement data by importing the files that contain it (i.e. by requesting ASAM ODS databases), or by receiving sensor data from measurement modules. This description of importing a DIAdem data file illustrates the producer-consumer structure.

First, we have to create a new instance of a DIAdem importer in jBEAM. This importer contains all the necessary information: how a DIAdem file is structured, and how to produce data items in jBEAM. In this example, the DIAdem importer creates two floating point channels named "Data Item 1" and "Data Item 2". The importer is therefore a "producer" that produces data items.

As an example of a data consumer, we create a graphic object of type "Universal 2D graph". In the graph, we define a chart of type "XY graph" whose input is now "Data Item 1". The measured values from the DIAdem file are then visualized automatically as a curve. The second data item ("Data Item 2") can be shown in a second diagram of type "XY curve", in the same graph; alternatively, we can define a second graph that shows the measured values as a diagram of type "XYcurve".

Instances of both producers and consumers are designated as "components" in the jBEAM software architecture.

Example: File import and visualization of imported data

Automatic update

Once the configuration of a producer has been modified, all consumers are instructed to recalculate their data or redraw the displayed data. Thanks to the automatic update mechanism, only those consumers that actually consume changed data items need to be updated.

For example, the DIAdem importer is modified using the importer dialog that contains all the DIAdem import parameters. One of these parameters is the file itself. If a different DIAdem file is chosen and confirmed, the following process will run:

  1. The content of the new file is loaded and stored in the data items. If the channel name or the type match, the existing items will be filled with new data.

  2. For each event, the data items inform all their consumers (in this case the graphic objects) that the content has changed.

  3. Now it is up to the consumer to react to this information. In this case, the graphics trigger redrawing.

The benefit: jBEAM's software architecture ensures that the status currently shown in jBEAM is correct – with no need to retrieve an auto sequence.

Branches and calculations

As well as data item producers and consumers, jBEAM contains many "calculations" that consume AND produce data items. Examples of these calculations include formulas, FFT analyses, crash assessments and event analyses.

In this example, we define a formula component with the formula "1.2 + 3*A" and "Data Item 1". The formula is applied to each value of "Data Item 1", and is stored in the "Data Item 3" channel that is produced. In this case, the automatic update also works if the imported file is changed.

Example: File import, channel calculation and visualization of data

External CEA components

External ASAM-CEA component in jBEAM

jBEAM is an ASAM-CEA compatible framework that can be extended with external plug-in components, provided they comply with the ASAM-CEA standard. In jBEAM, these external ASAM-CEA components function as if they were internal jBEAM components. Processing speed is maximized because the components are compiled.

The benefit: jBEAM's software architecture provides maximum flexibility to suit any application, with no compromises on usability or speed. Users have the advantage of an open framework that is easily adaptable to their specific needs.

Object architecture: classes – instances

jBEAM is object-oriented software that enables intuitive operation. However, users who are unaware of the correlation between classes and instances often encounter a pitfall – which we will now explain.

To use IT terminology: each importer, calculation and graph corresponds to a "class". This class includes all the important logics for these components. If, for example, we create a new calculation via the menu, an "instance" of this class is formed. This instance now contains parameters, and they may be different in each instance. For example: we could create five formula editors. These would be five different instances of the same class. Each of these five different formula editors may have different formulas or different input channels that are stored in the various instances.

If we now go to the formula editor in the menu, we can create a new instance. A dialog then opens automatically where the instance can be parameterized. If we want to modify this predefined formula editor again, we go to "Modify" to retrieve the list of existing instances. But when we return to the "Formula Editor" menu item, a new formula editor (new instance) is created – and we may be surprised to find that the parameterization dialog is in the initial setting, and all of our entries have disappeared.

The solution: if we need to change an existing component, we must go to go to the list of existing instances under "Modify".

お問合せ
(max 25 Mb)