I have a bunch of CAN signals going in and out of a system that I am working on. I want to specify the behaviour of the system in Rhapsody. I was planning on representing the CAN signals in Rhapsody as events carrying data. For example there is a 3 bit CAN signal LED_REQUEST which have the following coding:
0x4 NOT USED
0x5 NOT USED
0x6 NOT USED
I created an event evLedRequest carrying a value val with a custom data type LED_REQUEST_TYPE in Rhapsody. The data type is an enumeration with literals corresponding to the description of the values of the CAN signal:
I skipped the NOT USED values since I am only trying to reverse engineer the logical interfaces and to not care about which bits are used or not.
I continued to model all the CAN signals like this, but I then noticed that other CAN signals had value descriptions with the same string. For instance the signal BACKGROUND_LED_STATUS with the following coding:
Which resulted in the following data type:
When I then build the simulation Rhapsody complains that I have non-unique literals
A workaround is to just append an underscore in the literal name, but it bothers me:
Is there any better way of doing this? Can I force Rhapsody to have unique names for enumeration literals somehow? Should I model the data schema in a different way?
I have a work around that I use, but I don't have a GREAT work around. Basically, I munge the type name into the enumeration literal name when there is a possibility for a conflict. If OFF is an enumeration literal in type type, MICROWAVE_STATE and LIGHT_CONDITION, I would have the literals MVS_OFF and LC_OFF, or something like that. Again, it's not a completely satisfying solution, but it works.
Perhaps it is worth mentioning that there is no modeling or code generation issue here. You are getting an error message from the Cygwin compiler, because in C/C++ the same literal name cannot be used in multiple enums, even if it has the same value, like 0x0 for LIGHT_OFF. Other compilers, like Microsoft Visual Studio, will behave the same way.