SNIP_CLASSIC_STD_SECTION_4_4_10_Distributed_Shared_Mode_Queues

4.4.10 Distributed Shared Mode Queues In case different mode state machines are switched via synchronous mode switches, the order of their execution is basically undefined. Limited possibilities exist by using separate tasks for the different mode state machines. But these would globally give switches of one mode machine instance a higher priority than switches of another mode machine instance. In some cases it is required to keep the strict order of the mode switches, independent to which mode state machine they belong. One example, could be the key state (ON, OFF) and the engine state (RUNNING, STOPPED) which are technically independent mode machine instances, but have a functional connection. If the mode switch from key ON to OFF occurs first, followed by the switch from engine RUNNING to STOPPED, it was obviously the user’s intention to stop the engine. If the two transitions are executed in the reverse order, the system will see a switch from engine RUNNING to STOPPED while the key state is still ON which indicates a stalled engine which a start stop system might try to restart. This example shows how important it is for the application software to see the execution of the mode switches in the order they have been requested. As a result, it is required to have a mechanism to define a FIFO order for the mode switches of at least a subset of the mode machine machines in the ECU. A similar issue occurs in multi core systems in which user components on multiple cores have to react directly or indirectly on a mode switch. On one side it is already clear that in case mode disabling dependencies exist on multiple cores, to fulfill the requirements about the synchronous switching of these disabling dependencies, it is necessary to have one mode switch task per partition having mode disabling dependencies. But also in case there are SwcModeSwitchEvents in components of different partitions which react on switches of the same mode machine instance there have to be multiple tasks performing these switches as it is not legal to execute RunnableEntitys of a software component assigned to one partition in tasks belonging to another partition. To avoid that one partition is already in the new state while the other one didn’t even start the transition, it is also necessary to synchronize the mode switch tasks of multiple partitions, especially if they reside on different cores. This is important for the same reason as above. A component might expect a certain behavior of the system in a certain state. If now one partitions is still in the old state while another one is already in the new state, the expectation does not match reality with the consequence of functional misbehavior. A distributed shared mode queue is characterized by a set of mode machine instances and a set of OsTasks in which the mode switches of the participating mode state machines will be executed. [SWS_Rte_06832] Upstream requirements: SRS_Rte_00143, SRS_Rte_00310 ⌈The RTE Generator shall retrieve the set of mode machine instances belonging to one distributed shared mode queue from the set of RteDSMQModeMachineInstanceRef.⌋ [SWS_Rte_06833] Upstream requirements: SRS_Rte_00143, SRS_Rte_00310 ⌈The RTE Generator shall retrieve the set of DSMQ transition OsTasks belonging to one distributed shared mode queue from the set of RteDSMQOsTaskRefs.⌋ The OsTasks participating in a single distributed shared mode queue may or may not belong to a separate partition. If such OsTasks are belonging to OsApplications executed on the same micro controller core such DSMQ transition OsTasks have to be chained via the EcuC configuration. But not necessarily each partition will have an OsTask participating in a distributed shared mode queue. The OsTasks participating in a single distributed shared mode queue will only contain ExecutableEntitys mapped to this OsTasks via SwcModeSwitchEvents, BswModeSwitchEvents, ModeSwitchedAckEvents or BswModeSwitchedAck- Events referencing one of the mode machine instance participating in this distributed shared mode queue. [SWS_Rte_CONSTR_09102] Exclusive usage of OsTasks used for distributed shared mode queue ⌈An OsTask belonging to a distributed shared mode queue shall have only mapped on-entry ExecutableEntitys, on-transition ExecutableEntitys, on-exit ExecutableEntitys, and ModeSwitchAck ExecutableEntitys to it which are triggered by mode machine instances belonging to the identical distributed shared mode queue.⌋ Thereby [SWS_Rte_06839] constraints the order of the event to task mappings. Similar to the behavior defined in [SWS_Rte_02665] the execution of the mode switch may be triggered for each partition in parallel. If the partitions are executed on the same micro controller core the order depends on the priorities of the OsTasks or on a configured task chaining. In case partitions are executed on different micro controller cores, execution of the on-entry ExecutableEntitys, on-transition ExecutableEntitys, and on-exit ExecutableEntitys may run concurrently. [SWS_Rte_06834] Upstream requirements: SRS_Rte_00143, SRS_Rte_00310 ⌈The RTE shall trigger all OsTasks belonging to a distributed shared mode queue simultaneously, except the ones which are chained after another OsTask belonging to this distributed shared mode queue.⌋ [SWS_Rte_06835] Upstream requirements: SRS_Rte_00143, SRS_Rte_00310 ⌈The RTE shall execute the mode switches of the mode machine instances participating in a distributed shared mode queue in the order of the calls of the related Rte_Switch or SchM_Switch APIs.⌋ Thereby the queued mode switches of the mode machine instances of the same distributed shared mode queue are processed one after the other according the FIFO principle. [SWS_Rte_06838] Upstream requirements: SRS_Rte_00143, SRS_Rte_00310 ⌈The RTE shall switch at most one mode machine instance of the set of mode machine instances participating in a distributed shared mode queue at the same time into transition.⌋ The implementation of the behavior defined in [SWS_Rte_06835] requires a single mode queue which handles the queuing of the mode switches for all mode machine instances. In opposite to the mode machine instance local queues such a shared queue has to memorize which transition in which mode machine instance was notified. [SWS_Rte_06836] Upstream requirements: SRS_Rte_00143, SRS_Rte_00310 ⌈The size of the mode queue of the distributed shared mode queue shall be the sum of the individual queue lengths of all mode machine instances participating in this distributed shared mode queue.⌋ Nevertheless the RTE has still to check the individual queue sizes of each mode machine instances. This ensures, that each mode manager can always enqueue the maximum number of mode switch notifications reserved for this mode machine instances. [SWS_Rte_06840] Upstream requirements: SRS_Rte_00143, SRS_Rte_00310 ⌈If a new mode switch notification is received the RTE shall check if not more mode switch notifications of a particular mode machine instance are queued than the queue size of this particular mode machine instance supports. If the queue size would be exceeded, the RTE shall discard the received notification.⌋ In this case, Rte_Switch will return an error, see [SWS_Rte_02675]. The behavior described in [SWS_Rte_02665] has the consequence, that RTE / Basic Software Scheduler deactivates the previous mode disablings asynchronous on each core. But one major use case of distributed shared mode queues is the synchronization of activities across partitions. Therefore previous mode disablings deactivated by RTE after all on-exit ExecutableEntitys are executed. [SWS_Rte_06837] Upstream requirements: SRS_Rte_00143, SRS_Rte_00310 ⌈During a transition of a mode machine instance belonging to one distributed shared mode queue following steps are applicable: 1. [SWS_Rte_02661], 2. [SWS_Rte_07152] 3. [SWS_Rte_02562], 4. [SWS_Rte_07153], 5. [SWS_Rte_02707], 6. [SWS_Rte_02708], 7. [SWS_Rte_02564],