Editor: Using Messages
A message is the standard packet used to communicate data between components in the Nominal simulation suite. Messages are composed of a set of unique properties that are associated with a particular piece of information. They are also used for linking different modules together. Modules can have one of two different message types:
- In_Msg: An input message is a reference to a message that is required to be linked by the software or the user, as a way to specify a targeted set of data, that will change over the simulation.
- Out_Msg: An output message is a message instance that is managed by the component it is connected to. It controls the data that exists on the message and outputs the state after each update state.
This guide will cover how to utilize messages in Unreal using Nominal’s architecture and how to manage the data within messages.
Linking Messages
Each message has an owner component for the message. This is the component that predominantly writes data to the message parameters and changes the data over the simulation time. A single output message can be linked to zero-many other components, assuming they have the same message input type. Input messages are used as reference reading parameters, and those components should not be adjusting the values within those messages. An example of how messages can be linked together is shown in the guidance computer chain shown below:
Note
A guidance computer has several software chains that each link many messages between the chains; ensuring that the data can flow correctly between the nodes.
In Nominal Editor, the terminology for messages uses the In_ and Out_ standard syntax, indicating which message is an input and which is an output message. The type of message is also within the name; specifying the message type after the prefix. For example:
Out_NavigationTranslationMsg: [OUTPUT] Navigation Translation MessageOut_AttitudeReferenceMsg: [OUTPUT] Attitude Reference MessageIn_RWSpeedMsg: [INPUT] Reaction Wheel Speed MessageIn_DeviceStatusMsg: [INPUT] Device Status Message
Each message has its own class type and is shown in a blue colour in Nominal Editor. Messages can be plugged into different references between nodes, provided that the type matches. A message cannot be connected between an input and output pin if they are of different types.
Note
A general rule of thumb is to check that the input name and output name matches. For example, an Out_RWSpeedMsg variable can be plugged into an In_RWSpeedMsg variable.
Although many components can be linked with messages, the most common example is linking flight software modes when developing a custom flight software chain. For example, take the following snippet of a software chain found in Demo_SunEstimation:
In this case, each of the software modules has several input and output messages that can be exposed and linked together. The suffixes of the message names must match with each other for a valid link to be created. Additionally, for certain modules, certain messages can be left disconnected (if they can find the default).
Getting Messages
For any component that contains a message, both input and output, there are located under the following category:
Variables/Nominal Systems/Messages
Output messages can be returned from the component but cannot be set, as they are controlled by the component itself. Input messages can be returned from the component and in most cases can also be set to a different reference.
Setting Messages
For most input messages, the values can be set to another message reference, provided that the types match up. These are particularly useful for flight software where the module references are typically slotted together in a particular order.
Printing Messages
Messages can be printed using the To String function, which can output all of the data within the message and convert it to an appropriate string type. This can be useful for debugging and printing to the screen when something is going wrong.
Depending on the message, the data will be displayed on the screen in different forms, based on what parameters are available on the individual message.
Reading and Writing Message Data
Each message can have its properties read from and written to. This can be done using the associated variables located on the object, which are based on the class of message used. These can be edited like any other object in Unreal.
Note
All variables will be located under the ‘Variables’ category and this will contain both the getters and setters for all data on the object.
Creating Messages
Sometimes, new messages are required to be created and inserted into the system. The messages are created in Blueprints and connected to the input messages of other components. This ensures that the output messages are not being overridden, whilst providing full control for the user to update the data correctly and manage the data over time. The Create Message function exists to create messages with the initial data from the message exposed. The simulation owns these messages (the user), which means they are not tied to any particular component.
With the Create Message node, a message class must be selected or else a compiler error will be thrown. Once the message class is selected, the variables for that class will be shown (along with their default values) and the return value will be of the type that was specified in the class.
Once created, the messages can be handled in the same way as before, allowing for reading, writing and linking to other components. The following example shows replacing the Attitude Guidance Message with a new custom message that can be defined in Blueprints.
Storing Messages
Like any object type, the messages can be stored as variables in Blueprints. These can be useful for manipulating data later in the simulation or for fetching the object at any time. To store a message, either create a new variable of the correct message type or create it from the Create Message node as seen below.
