FAQ

Error message: [FatalError - RealTimeApplication.cpp:73]: Could not stop the RealTimeApplication. Was it ever started??

The destruction of the RealTimeApplication object is being attempted without the application having been started. This can be caused by a failure during the startup phase of the application, which prevents the application from reaching the state where it is considered “started”. It is rarely the root cause of the issue, but rather a consequence of an earlier failure during startup. To identify the root cause, it is necessary to look at the log messages that appear before this error message in the application log.

[FatalError - Reference.cpp:129]: Reference: Failed CreateByName() in constructor… [FatalError - ReferenceContainer.cpp:421]: Failed to Initialise object with name …

The application could not instantiate the object for the type specified in the Class = field.

This can be caused by a typo in the class name, by the class not being available as part of the LD_LIBRARY_PATH, or because it is part of a library and the class name needs to be prefixed with the library name. For example, if the class is part of the library MyLibrary, the class name should be specified as Class = MyLibrary::MyClass.

What are the rules for signal naming in the configuration file?

Typically, GAMs and DataSources do not force signals to have specific names, and the user is free to choose the signal names in the configuration file.

Users should, however, check the component documentation to see if there are any specific requirements or conventions for signal names, as some components may impose signal names or conventions.

For example, in the HelloWorld application, the signal produced by the GAMTimer is named Counter. This name is not fixed and can be changed to any other valid name without affecting the functionality of the application, as long as the signal connections are correctly updated in the configuration file.

For example, the configuration files RTApp-HelloWorld-1.cfg and RTApp-HelloWorld-11.cfg are totally equivalent.

Before
 1        +GAMTimer = {
 2            Class = IOGAM
 3            InputSignals = {
 4                Counter = {
 5                    DataSource = Timer
 6                    Type = uint32
 7                }
 8                Time = {
 9            Signals = {
10                Counter = {
11                    Type = uint32
12                }
13                Time = {
After
 1        +GAMTimer = {
 2            Class = IOGAM
 3            InputSignals = {
 4                Ticks = {
 5                    DataSource = Timer
 6                    Type = uint32
 7                }
 8                Time = {
 9            Signals = {
10                Ticks = {
11                    Type = uint32
12                }
13                Time = {
What are the available signal properties?

See the Signal properties documentation for a complete list of available signal properties.

What are the available signal types?

See the MARTe Types documentation for a complete list of available signal types.

Can I use structured types for the signals?

Yes, see the GAM documentation and the tutorial on Structured types.

What are the available GAM properties?

All the MARTe component properties, including those of GAMs, are specific to the component and are documented in the component API documentation.

Warning

The component properties are processed by the component itself, and properties that are not recognised by the component will be ignored.

This means that if a property is misspelled or if a property is used that does not exist for the component, the application will still run without any error message, but the property will not have any effect on the behaviour of the component.

In the following example, the property Frequency in the GAMTimer outside the InputSignals is ignored:

 1$HelloWorldApp = {
 2    Class = RealTimeApplication
 3    +Functions = {
 4        Class = ReferenceContainer
 5        +GAMTimer = {
 6            Class = IOGAM
 7            Frequency = 1000
 8            InputSignals = {
 9                Counter = {
10                    DataSource = Timer
11                    Type = uint32
12                }
13                Time = {
14                    Frequency = 1
15                    DataSource = Timer
16                    Type = uint32
17                }
18            }
What are the available DataSource properties?

All the MARTe component properties, including those of DataSources, are specific to the component and are documented in the component API documentation.

Why do I see the acronym “DDB” in many configuration files?

The DDB is the name of the original implementation of the GAMDataSource in MARTe1. It is used interchangeably with GAMDataSource in MARTe2, and it is still present in many configuration files for historical reasons. The DDB is a simple DataSource that provides an interface for GAMs to exchange data between each other, without any connection to external hardware or software.