Hi Bruce, I have had this question on my mind for a while and now I actually had to put it to the test in a real project. The problem I have a system where there are explicit requirements for power consumption. There are three so called power states that the system must have: - Operational state - Max 45 mA - Standby state - Max 5 mA - Sleep state - Max 0,6 mA The transitions between these states will be controllable by external signals. I therefore created a separate use case for this called StartUp_Shutdown (SU_SD) , see below: I also added the Unpowered and Powered states. The system also contains a control function. The modes of this function according to the requirement will be: - Off - Control - Error I created a separate use case for this and called it Shift Gear (SG): When the control function is Off, it is supposed to enter a lower power consumption state and here is where my brain starts to hurt. Apparently the SG uc needs to communicate with the SU_SD uc, since when the SG uc is Off, it is supposed to enter sleep or standby in the other uc in order to satisfy the requirement. But then I hear the echo of your words on p 152 in Agile Systems Engineering that good use cases are independent and that only in an extremely rare case do you (< 1%) do you need to have an association between use cases in order to co-simulate them. I don't understand this. For me there is typically always an association with the power states of a system and the different modes of the different main functions of the system. Even in your own Harmony aMBSE Deskbook you have the stm for the Uc_ControlAirSurfaces that contains the same states as in the Start Up use case proving that the use cases are dependent! So I am now thinking on how to solve this, should I have create an execution context for both use cases simultaneously? Or should I merge the two use cases to one? I am thinking about about having a Composited block owning a stm as you suggests in State Machine Corner Episode 6: Return of the AND-States which would then contain the two use case blocks. Thanks!

Hello everyone, I am using Rational Rhapsody Developer for C (version 8.1.3) and FreeRTOS on our Project. In the Project there are 20 tasks (20 different classes). While the application running, the code crashes after a while and I’ve seen that the code can’t exit while loop; ( pReactive can’t be equal curDest ) RiCBoolean RiCTimerManager_unschedTm(RiCTimerManager* const me, RiCEventId id, struct RiCReactive_t * const pReactive) { /*#[ operation unschedTm(RiCEventId,struct RiCReactive_t * const) */ RiCBoolean unschedTmRes = RiCFALSE; if(me != NULL){ RiCEvent *currentTm = me->timeouts; RiCEvent *previousTm = NULL; /* critical section for the timeouts structure */ RiCOSMutex_lock(&(me->CSMutex)); /*LDRA_INSPECTED 53 D : Pointer is initialized before use */ /*LDRA_INSPECTED 69 D : Variable is assigned before use */ while (currentTm !=NULL) { RiCEventId curId = RiCTimeout_getTimeoutId(currentTm); const RiCReactive * const curDest = RiCEvent_getDestination(currentTm); if(((id == curId) || (id == RiCAnyEvent_id)) && ( pReactive == curDest )){ /* remove tm from list */ if(currentTm == me->timeouts){ /* first item */ me->timeouts = RiCTimeout_getNextTm(currentTm); } else{ /*LDRA_INSPECTED 45 D : Variable is checked inside of function */ RiCTimeout_setNextTm(previousTm, RiCTimeout_getNextTm(currentTm)); } /* delete tm */ RiCTimeout_setNextTm(currentTm, NULL); RiCTimeout_destroy(currentTm); if(id != RiCAnyEvent_id){ currentTm = NULL; } unschedTmRes = RiCTRUE; } if (currentTm !=NULL) { previousTm = currentTm; currentTm = RiCTimeout_getNextTm(currentTm); } } /* critical section for the timeouts structure */ RiCOSMutex_free(&(me->CSMutex)); } return unschedTmRes; /*#]*/ } Any idea what may cause this problem? Thanks in advance.

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: Value Description 0x0 LIGHT_OFF 0x1 LIGHT_ON_DAY 0x2 LIGHT_BLINKING 0x3 BACKLIGHTING 0x4 NOT USED 0x5 NOT USED 0x6 NOT USED 0x7 LIGHT_ON_NIGHT 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: Value Description 0x0 LIGHT_OFF 0x1 LIGHT_ON 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?