MsgId abstraction - add API to translate between topic ID and MsgId

[jphickey]

Is your feature request related to a problem? Please describe.
Currently applications hard-code the MID value they use for both publication of telemetry and subscribing to commands and/or telemetry from other applications. This is typically done via a header file such as ${appname}_msgids.h.

The problem is in a multi-CPU environment this is a barrier (and often the only barrier) to having a single binary build be loaded onto multiple processors

For core apps within CFE, this is already done by assigning a message "topic ID" to each core app, which is an offset from a base MID. For instance, in cfe_mission_cfg.h we have:

cFE/cmake/sample_defs/sample_mission_cfg.h

Lines 380 to 381 in d217ca3

	#define CFE_MISSION_CMD_MID_BASE1 0x1800
	#define CFE_MISSION_TLM_MID_BASE1 0x0800

And "topic" definitions:

cFE/cmake/sample_defs/sample_mission_cfg.h

Lines 411 to 428 in d217ca3

	#define CFE_MISSION_EVS_CMD_MSG 1
	/* Offset 2 is available */
	#define CFE_MISSION_SB_CMD_MSG 3
	#define CFE_MISSION_TBL_CMD_MSG 4
	#define CFE_MISSION_TIME_CMD_MSG 5
	#define CFE_MISSION_ES_CMD_MSG 6
	#define CFE_MISSION_ES_SEND_HK_MSG 8
	#define CFE_MISSION_EVS_SEND_HK_MSG 9
	/* Offset 10 is available */
	#define CFE_MISSION_SB_SEND_HK_MSG 11
	#define CFE_MISSION_TBL_SEND_HK_MSG 12
	#define CFE_MISSION_TIME_SEND_HK_MSG 13
	#define CFE_MISSION_SB_SUB_RPT_CTRL_MSG 14
	#define CFE_MISSION_TIME_TONE_CMD_MSG 16
	#define CFE_MISSION_TIME_1HZ_CMD_MSG 17

And in cpu1_msgids.h this organizes it into message IDs by topic:

cFE/cmake/sample_defs/cpu1_msgids.h

Lines 47 to 64 in d217ca3

	#define CFE_EVS_CMD_MID CFE_MISSION_CMD_MID_BASE1 + CFE_MISSION_EVS_CMD_MSG /* 0x1801 */
	/* Message ID 0x1802 is available */
	#define CFE_SB_CMD_MID CFE_MISSION_CMD_MID_BASE1 + CFE_MISSION_SB_CMD_MSG /* 0x1803 */
	#define CFE_TBL_CMD_MID CFE_MISSION_CMD_MID_BASE1 + CFE_MISSION_TBL_CMD_MSG /* 0x1804 */
	#define CFE_TIME_CMD_MID CFE_MISSION_CMD_MID_BASE1 + CFE_MISSION_TIME_CMD_MSG /* 0x1805 */
	#define CFE_ES_CMD_MID CFE_MISSION_CMD_MID_BASE1 + CFE_MISSION_ES_CMD_MSG /* 0x1806 */
	#define CFE_ES_SEND_HK_MID CFE_MISSION_CMD_MID_BASE1 + CFE_MISSION_ES_SEND_HK_MSG /* 0x1808 */
	#define CFE_EVS_SEND_HK_MID CFE_MISSION_CMD_MID_BASE1 + CFE_MISSION_EVS_SEND_HK_MSG /* 0x1809 */
	/* Message ID 0x180A is available */
	#define CFE_SB_SEND_HK_MID CFE_MISSION_CMD_MID_BASE1 + CFE_MISSION_SB_SEND_HK_MSG /* 0x180B */
	#define CFE_TBL_SEND_HK_MID CFE_MISSION_CMD_MID_BASE1 + CFE_MISSION_TBL_SEND_HK_MSG /* 0x180C */
	#define CFE_TIME_SEND_HK_MID CFE_MISSION_CMD_MID_BASE1 + CFE_MISSION_TIME_SEND_HK_MSG /* 0x180D */
	#define CFE_SB_SUB_RPT_CTRL_MID CFE_MISSION_CMD_MID_BASE1 + CFE_MISSION_SB_SUB_RPT_CTRL_MSG /* 0x180E */
	#define CFE_TIME_TONE_CMD_MID CFE_MISSION_CMD_MID_BASE1 + CFE_MISSION_TIME_TONE_CMD_MSG /* 0x1810 */
	#define CFE_TIME_1HZ_CMD_MID CFE_MISSION_CMD_MID_BASE1 + CFE_MISSION_TIME_1HZ_CMD_MSG /* 0x1811 */

Offsetting a base MID by a topic value is a completely logical way to solve the issue of running the same code on multiple CPUs and assigning different MID values, but CFE_SB_MsgId_t values are supposed to be abstract. There should be no assumption that they can be added together like this.

Additionally, the same translation should be implemented as a runtime API, rather than forcing the value to be computed only at compile time.

Describe the solution you'd like
Add a new API to software bus that allows determining a MID value at runtime, given a topic ID along with an instance number.

For instance:

CFE_SB_MsgId_Compose(uint16 TopicId, uint16 InstanceNum, CFE_SB_MsgId_t *MsgId);
CFE_SB_MsgId_Decompose(CFE_SB_MsgId_t MsgId, uint16 *TopicId, uint16 *InstanceNum);

This can be further simplified for "Local" requests by getting the instance number from the PSP, for example, something like:

CFE_SB_MsgId_t CFE_SB_MsgId_From_TopicId(uint16 TopicId);

Would return the MID of the topic on the current/same CPU.

Topic IDs can be assigned exactly as they are today (at least for now), because they can be assigned at mission scope and are agnostic to CPU/instance number.

Furthermore, the translation between topic ID and and MsgId need not be limited to a simple addition/bitmask - the conversion can be a implemented in a user-supplied library and customized based on however a mission chooses to allocate its MID values for routing.

Subscription requests would then be simplified. For example in ES, the HK subscription in:

cFE/fsw/cfe-core/src/es/cfe_es_task.c

Lines 292 to 296 in d217ca3

	/*
	** Subscribe to Housekeeping request commands
	*/
	Status = CFE_SB_SubscribeEx(CFE_SB_ValueToMsgId(CFE_ES_SEND_HK_MID), CFE_ES_TaskData.CmdPipe,
	CFE_SB_Default_Qos, CFE_ES_TaskData.LimitHK);

Would become:

Status = CFE_SB_SubscribeEx(CFE_SB_MsgId_From_TopicId(CFE_MISSION_ES_SEND_HK_MSG), CFE_ES_TaskData.CmdPipe,
                                CFE_SB_Default_Qos, CFE_ES_TaskData.LimitHK);

This would in turn make all the msgids.h header files obsolete and unnecessary... because all CPUs can use the same topic IDs and translate at runtime.

Describe alternatives you've considered
Message IDs can also be assigned in a separate configuration table and loaded via TBL services, which is supported today if the application is written that way, but most are not.

For apps that don't already use TBL services for config, it is a fairly substantial change to add it. It is significantly easier to change the API used to translate the MID as proposed here to make the app CPU/instance agnostic, rather than introduce a configuration table for this purpose.

Additional context
Obviously not for CFE 6.8... but recommended to discuss for 6.9/7.0 or whenever.

We might want to consider changing the name from CFE_MISSION_EVS_CMD_MSG to CFE_MISSION_TOPICID_EVS_CMD (or something) to make it clearer. But fundamentally its OK, and it still would apply even if the topics are assigned by a tool/database of some type in the future.

Requester Info
Joseph Hickey, Vantage Systems, Inc.

[skliper]

How about mission/platform/type/topic?

get_msgid_full(mission, platform, type, topic) where mission is spacecraft_id or whatever mission identifier makes sense...
get_msgid_mymission(platform, type, topic)
get_msgid_myplatform(type, topic)

Just needs a global mapping for translations to/from header field values.

This may help @tngo67, if a mission may want to remove type from their msgid hash such that it doesn't have to be a 50/50 split.

[jbohren-hbr]

@jphickey Is there an overhead concern with runtime translation from topic IDs to message IDs?

[skliper]

It really shouldn't be additional runtime work. Right now message handlers get the message ID, they'd just be getting the topic ID instead (they are both just related to bits in the header... ). SB would still use the message ID for routing, and the full message ID needs to go into the associated routing table, it's just that apps could use the topic ID to subscribe and route and the rest of the info to come up with the full message ID for the local system could be done under the hood. Note CCSDS already has the concept of system and subsystem... but these are used in different ways by different organizations. The abstract concept of topic ID can be implemented under the hood however a mission desires (much like message ID).